Video thumbnails create multiple threads (1 Viewer)

[gloomyandy]

MediaPortal Version: SVN Build 1ab1 (20.12.2006 / 13:51 CET)
MediaPortal Skin: Blue Two
Windows Version: XP Home SP2
CPU Type: AMD 64X2 4200+
HDD: Samsung 200Gb
Memory: 1Gb DDR
Motherboard: ASUS P1-AH1
Motherboard Chipset: nVidia MCP 51
Motherboard Bios:
Video Card: nVidia GeForce 6150
Video Card Driver: 91.47
Sound Card: Realtek high def
Sound Card AC3: no AC3
Sound Card Driver: 5.10.0.5296
1. TV Card: Hauppauge HVR-1300
1. TV Card Type: DVB-T/Analogue hybrid with mpeg hw encoder
1. TV Card Driver: 2.5e
2. TV Card: Hauppauge Nova T-Stick
2. TV Card Type: DVB-T
2. TV Card Driver: 2.5e
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec: Intervideo XPack 2.11.15
MPEG2 Audio Codec: Intervideo XPack 2.11.15
Satelite/CableTV Provider: NTL
HTPC Case: ASUS Pundit P1
Cooling:
Power Supply:
Remote: MS MCE
TV: Hyundai Q320 32" LCD
TV - HTPC Connection: DVI

If you have TV programs that cause the GrabBitmaps function not to return (and I seem to have a few). Then every time you visit the RecordedTV display a new Thread is used from the ThreadPool. Basically each thread gets stuck in the GrabBitmaps function. If MP suspends itself the threads get woken up, but in my case they just move on to the next TV program that again causes a hang. The attached log file shows this for two visits to RecordedTV. The attached vmr9.log file shows the GrabBitmaps call not completing until the system is suspended.

Thanks

Andy

 

[rtv]

yeah - this is intended, unfortunately the GrabBitmaps is some C++ code which doesn't even build here therefore we've to wait until Frodo may find some time to look at this.

 

[gloomyandy]

Hi rtv,
Thanks for taking a look at this. The thing I don't understand is why it makes sense to ever run multiple threads to create the thumbnails. If the first does not complete why bother creating a second (since it will probably also get stuck in the same place)? Would it not make more sense to only start a new one if the previous thread has completed?

I think some of the other parts of the system (photos?) do the same, but I'm not sure that makes sense either. I've seen errors in my log files which seem to be a result of multiple thumbnail threads running in the same photo dir. What seems to happen is that one thread gets to create the thumbnail then the other thread gets an error trying to create the same thumbnail (presumable because the file now already exists). Not sure if everyone will see this or only those (like me) with dual core systems. To see this problem on my system I simply need to do the following...
1. Create a dir full of photos with no thumbnails already existing.
2. Browse into this dir using mp (this create a worker thread to create the thumbs).
2. Step back up out of the dir and out of MyPictures.
3. Return to the same dir (this creates a 2nd thumbs thread).
4. Look at log files I see several GDI+ errors from the two threads creating the thumbs.
The errors don't seem to do any real harm, but Im not sure the extra threads do any real good. I guess that if the threads are running in different dirs then they would be able to do both at once...

Thanks for your help

Andy

PS I did try and take a look at GrabBitmaps but I had the same problems (not able to build the c++ code). Oh well!

 

[rtv]

Okay, MrHipp patched the DX-SDK to be able to compile the lib. Now there is a timeout of 15 seconds for the GrabBitmaps function.

The serveral threads will NOT try identical work since every async request handled by the threadpool will have it's own path to work on. In addition each thumbnail creation is preceeded by a file.exists() check to make sure no "useless" work is done. You can of course provoke such a situation currently e.g. when chosing to create thumbs manually (which WILL overwrite existing ones by intention) while MP is still doing the auto-create on entering a "new" folder.

For big picture folders I'll maybe use a delegate request like scrobble lookups do and cancel a still running request when a new one is created.

This might punish "stupid" users with decreased speed but would be safe then.

 

[gloomyandy]

Hi rtv,
The problem I've seen with photo thumbs is that there is a race condition with the file.exists check. What seems to happen is this...

Thread 1 starts off and checks image1 no thumb so creates it. Then moves on to image2 again no thumb so starts to create it (note that this operation takes time and the file is not created until the thumb has been created). Thread 2 starts checks image1 already exists, checks image2 which currently does not exist (because thread1 is in the process of creating it...), so thread2 then also begins to create the thumb. Which ever finishes first creates the file, and when the other thread attempts to create the thumb file it gets an error.... This process then continues with a collision every now and again. I see a whole stream of GDI+ errors if I follow the steps outlined above... There is no real harm done but it does waste cpu and you get errors in the log...

Andy

 

[gloomyandy]

Oh and thanks for the changes to add the timeout. I will download the updated svn and check it out. Will get back with the results!

Andy

 

[gloomyandy]

Have just tested in latest svn and I can confirm that the new timeout on the GrabBitmaps function works well. The thread no longer gets stuck on any of my recorded files (though they do not get thumbnails as expected).

Many thanks

Andy