View Single Post
barbieri's Avatar
Posts: 44 | Thanked: 21 times | Joined on Dec 2007 @ Recife, Brazil
#64
Originally Posted by pycage View Post
Opening the image browser makes Canola crash frequently. I have a test image in there with 18 megapixels resolution. Canola should refuse to load/thumbnail such a thing instead of crashing.
Yeah, this is something hard. We try to use some tricks, like opening images at 1/2, 1/4 or 1/8 if they are JPEG, since this is possible and should not take much memory, but 18mpx is quite a lot, even in that case.


Originally Posted by pycage View Post
When quitting Canola, atabake remains in memory, eating away several MB of RAM. I have to kill it manually (this was the same with beta 9).

When Canola crashes, atabake and canolad remain in memory and have to be killed manually (this was the same with beta 9).
How long did you wait? They have a timeout of 30 seconds (maybe more, I didn't write this and last time I checked was long ago). They listen for DBus's NameOwnerChanged and when last user disconnect they'll wait that amount before shutting down. This is in the case user wants to quit Canola for some reason and quickly restart it, you'd not have to wait these daemons to load.


Originally Posted by pycage View Post
The Happy Tree Friends videocast contains hires m4v Videos (e.g. HTF_Kringles_Reindeer_iPhone.m4v) which are not playable on the device. OSSO media player refuses to play, and mplayer plays them totally jerky, dropping about every single frame.
And what kind of solution do you propose? Not clear to me.

Originally Posted by pycage View Post
Ogg-out-of-the-box still remains a dream. I don't like to use apt-get or search for a package that seems totally unrelated to Canola (lightmedia-scanner-ogg) for getting Ogg support. It should work out of the box. A media player that does not play Ogg or FLAC is near to useless to me, since most of my audio files are in these formats.
(I got Ogg working now, because I knew about the lightmedia-scanner-Canola relation, but many users may not).
Yes, our bad. We forgot to upload 2 packages: applet and ogg. With them it would make more sense :-)

Originally Posted by pycage View Post
If you have a reasonably high number of video files on your device (>150 in my case), you can go make a coffee while Canola-Tuning creates the thumbnails. I think the thumbnails should be created on-demand, not all at once.

Whenever I add new videos and want to have thumbnails created for those as well, I need to go through the whole process of creating >150 thumbnails again. Time for another cup of coffee... :/
Video thumbnail is also tricky... it's hard to figure out correct frames and all. And this is done by Canola-Tuning, since it uses MPlayer, we cannot force Canola to depend on it and thus we cannot request on demand, as we do with picture thumbnails.

Originally Posted by pycage View Post
Sometimes mplayer is really jerky when playing FLV embedded in Canola or MediaBox. This is especially true when you have run liqbase before and didn't reboot your device since then. liqbase seems to manipulate the CPU scaling governor permanently. I'm still investigating this problem.
Unfortunate situation :-/ But good to know nonetheless.

Originally Posted by pycage View Post
Most of my cover art is located in the folder of the songs as PNG or JPEG (e.g. cover.jpg). Canola-Tuning doesn't find any of these. Nor does it find any coverart embedded in ID3 tags. I think earlier versions of Canola-Tuning where better at finding my cover art.
Weird, this should work. Anyway, that code is open and you can freely check what's up with it. Patches are welcome ;-)

Originally Posted by pycage View Post
Hardware buttons don't work for zooming images.

Image panning in the image viewer is not kinetic, so doesn't really fit the rest of the user interface...
This is on the roadmap for next release. We have few things to do, possibly you will like it.

Originally Posted by pycage View Post
I think the transition effects in the UI where smoother (more FPS) in earlier versions.
No, it's actually a bit faster and you can even see some animations you could just see on desktop before. But that changed the flickering/tearing effect and in some screens they're even more noticeable. This is specially true for photo-walls, now we use asynchronous image loading, so we block much less and we load much more images than before, animation is bit faster and these together give the impression it's jerky, weird, we know... trying to solve by changing some constants to match these problems.
 

The Following User Says Thank You to barbieri For This Useful Post: