Notices

Canola Beta 9 on a reflashed n810 is not able to scan any media.
When run as canola -vv the following error is printed during scan:

File "/usr/lib/python2.5/site-packages/dbus/service.py", line 696, in _message_cb
retval = candidate_method(self, *args, **keywords)
File "canolad/daemon.py", line 245, in scan_all_paths
AttributeError: 'Daemon' object has no attribute 'mger_tab'

1222900497.8579 INFO ui:313:stop() Rescan timeout, finishing before unlock signal.

All video and audio menus show "No items found"

I installed beta9 on 770 with OS2006 as a test does this device could be used as media player.

Selecting MP3 file from local storage (internal flash) require several seconds wait on 'playing' screen before song will be played at all.

HRw: you're facing a really heavy known problem from the gregale (2006): Dbus version is quite old and it takes really a while to the "play" command to be properly executed and return to canola. So indeed it takes a long time.

Those kind of issues made us drop support for those devices / firmware versions:
we cannot upgrade it's dbus (it would break the basic software) and then we are stuck with the problem.

Sorry for the trouble, but this problem is way beyond our capabilities for now. Maybe we could improve it, but we are focused on chinook and diablo only.

BR

Marcelo

I frequently get an issue where, if I try to select the middle of a podcast before it starts playing - drag the slider to the middle of a track before playback starts - then Canola locks up completely, forcing me to press home, then kill the process. I also kill canolad. Half the time this works, but the other half I am forced to re-boot the tablet. Could this be a python issue?

Happy to post logs if you let me know what you need.

Also, when listing podcasts, the time between selecting one to play and the "click" response can be 4-6 seconds.

No.

I don't know the Canola source code, but my guess is that Canola waits for a certain response by the mediaplayer backend which doesn't come if you seek before playback starts. This would also explain why the application takes several seconds to respond after clicking. It might wait for an event to happen while the backend is buffering the stream.
It should be reported as a bug to the Canola developers that waiting is fully blocking in this case.

Okie doke. Will do.

Red: Pycage is indeed right, this is half a bug, half a problem in the Mediaplayer backend, that sometimes takes too much to receive / answer to the dbus or simply doesn't report an error.

But the slide thing it's a known bug, we will just make sure it's on bugzilla and try to fix it!

Marcelo

I posted a bug on page 23 of this thread and I recently found the issue. I had the Diablo Extras repository and another Extras Repository that did not specify a specific version. Once I edited that repo to be the Chinook Extras repo and did an "apt-get install canolad" it upgraded several things and Canola worked.

I know someone else had the problem, so I hope this works for you.

One thing I would love is for there to be a bookmark feature for those of us with extensive audiobook collections. It is especially helpful when some files are over an hour long. It can be a pain to remember where you left off when switching between files.

Besides that, this is a pretty brilliant mediacenter- if a little bit of a memory hog.

Ralob : yeah, as it's graphic intensive it indeed uses more memory, but I can assure you that apart from that we made a lot of improvements from memory consumptions from version 1

About the bookmark, still a buggy feature (in podcast only) but I've started am audio book plugin to Canola with some university students, that will fullfill this

Marcelo