Re: MediaBox Media Center 0.96 with UPnP and more
 

Artists don't support pictures yet.
For albums, MediaBox looks for an image file in the same folder as the file (not necessarily folder.jpg) and takes this. Alternatively it's also possible to embed the cover art in the ID 3 tags of the files.

Re: MediaBox Media Center 0.96 with UPnP and more
 

Mplayer connection has become even more unstable (mplayer hangs sometimes, also starts showing video when MediaBox is in the browser mode). Startup time has gone way up since the last version. Also (just like the last version), there are quite noticeable (several seconds) delays when you click on some interface buttons. Not using swap.

Re: MediaBox Media Center 0.96 with UPnP and more
 

This sounds really bad. Are there other applications running at the same time that consume CPU?
How long is your startup time for MediaBox?
Delays of several seconds in the interface sounds like something is going really wrong.

Re: MediaBox Media Center 0.96 with UPnP and more
 

Not really. There is FBReader running, but it is not doing anything at the moment.

About 15-30 seconds.

There are two kinds of delays:

1. When MediaBox transitions between screens (like when showing a video or showing a list of items) there is a 2-5 second delay with 100% CPU load, most likely due to actual processing in Python (have you considered changing to C/C++? :))

2. When I scroll through a list, MediaBox sometimes hangs up for 0.5-2 seconds, maybe due to Python garbage collection.

Re: MediaBox Media Center 0.96 with UPnP and more
 

OK, FBreader should be no problem.

I get about the same. Here's my comparison (from clicking of icon to application ready):
- MediaBox 0.96.4 with all plugins installed: 29.8 s
- Canola2 with UPnP plugin installed: 22.7 s

Your startup time doesn't look too bad and I don't think I saw it any better with 0.96.3. But there's still room for improvement.

The transition between video and list of items seems to be taking longest time. I'm going to put more focus on this. But I don't think that changing to C/C++ would bring much performance gain. The bottleneck is rendering and that's GDK and thus on C level already. The key is to minimize the amount of rendering.


While scrolling through a list, the thumbnails are loaded from file when needed. Maybe a slow memory card causes this delay. But even on my 770 I don't get a delay of 2 seconds. Unfortunately it's not possible to hold the thumbnails in memory, because RAM is too limited. With hundreds or thousands of thumbnails this is simply impossible.
Have you tried another memory card. You can also try to force MediaBox to create the thumbnails again (Preferences -> Media Indexing).

Re: MediaBox Media Center 0.96 with UPnP and more
 

Neither MediaBox's nor Canola's startup times are really acceptable, as they both violate the infamous 7-second rule (the amount of wait time after which the user starts looking for a sledgehammer). So, if there is anything that can slash the loading time, apply it by all means :)

Once the scrollable list shows up, it looks to be filling up asynchronously. Only small part of the list (5-7 items) is shown at any moment of time. So, what part of rendering contributes to that delay?

I doubt that scrolling delays are directly caused by the thumbnail rendering (they may though, and then it is all up to the filesystem responsiveness). Instead, they may be caused by garbage collection or some other internal process in Python. If it is true, then it would be fixable by preallocating all memory for the list before scrolling it.

Re: MediaBox Media Center 0.96 with UPnP and more
 

I think I'm making some good progress there. :)
The next release should startup faster. But 7 seconds on the N8x0? Not even microB achieves this (just measured; 9 seconds).

As weird as it sounds, it's a full screen rendering because of changing the layout and the toolbar contents. I'm now trying to minimize the amount of rendering a bit further. Especially the toolbar stuff should be optimizable.

It's all preallocated in the list. The same offscreen pixmaps are used over and over again for rendering the items. When you scroll, this is what happens:

The screens contents are moved by the amount that you scroll (Xserver-side pixmap copying). Only the newly visible items get rendered. Every time a new item with a thumbnail gets rendered, the thumbnail has to be read from file. There is some thumbnail and item caching involved, too, for speeding up the process, but these caches can't hold many items.

The time consuming parts I see are thumbnail loading and maybe rendering the text. Have you checked the resolution of thumbnails? Maybe some are really big (due to a bug in an earlier version of MediaBox) and thus cause long loading. Text rendering can take some time when pango has to lookup new characters (e.g. for displaying CJK characters), but once the characters are loaded the delay won't happen again.
I have never seen garbage collection kick into action while scrolling.

It would be interesting to see what happens when you disable thumbnail loading and rendering by opening /usr/lib/mediabox/components/media_viewer/MediaItem.py and commenting out the line with
.
Likewise you can try commenting out the other things such as or (for the background of the item).

Re: MediaBox Media Center 0.96 with UPnP and more
 

playing worldtv in MDBox would want to skip to the next media after few seconds of play, i continue to tap on the intended media to keep it playing is this a bug in MDB or worldtv? can't keep it to continuosly play one tv media

Re: MediaBox Media Center 0.96 with UPnP and more
 

It happens when the server reports the stream "finished". Still, I do not think MediaBox should go to the next channel in this case: this behaviour is only justified for songs, but not for the video and definitely not for the internet streams.

Re: MediaBox Media Center 0.96 with UPnP and more
 

Ah, I wouldn't use MicroB as a benchmark here :)

I do full screen rendering on n810 at about 15fps using C, with some assembler acceleration. Consider skipping on GDK completely and using SDL + some handcoded stuff instead: you may be losing time due to GDK issues.

Sounds perfectly reasonable, shouldn't be a problem.

Naah, no CJK here, so it should not be an issue :)

I will experiment with this stuff tonight and report findings in this thread. Another interesting idea would be to profile the whole thing using non-intrusive profiling tools. This requires a special Linux kernel though.