Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Channel switching race condition in VDR?



Background:

I've implemented a (very kludge) subtitle streaming over streamdev. Subtitle
plugins (subtitles + ttxtsubs) need to read the SI information to know the
subtitle PID, teletext page, languages infos etc. Plugins use
cStatus::ChannelSwitch() to read the information directly from the DVB card.
It may take some time to wait for the SI section to be received.

What appears to happen (rarely) is that the plugin ChannelSwitch() is
entered a second time before the first call is finished. This is quite
fatal, if the frequency of the device changes when the plugin still thinks
it's reading SI sections for the first channel switch. On this case the
subtitle info is read wrong (or not received), and what makes this worse is
that plugins cache the info and VDR needs to be restarted to make plugin to
read the info again. 

This seems to be related with the situation where the channel change in the
streamdev server is triggered by the streamdev client, and the channel
change fails for some reason. Then streamdev client (?) immediately tries to
switch to the old channel. What makes it worse is that subtitle plugins
cache the (wrong) SI data, and subtitles are not shown or recorded until VDR
is restarted.

A Lock() and Unlock() calls around the body of the method
cDevice::SetChannel() appears to fix this. I guess this will be fixed
automatically when plugins can read the SI sections from VDR itself.  But
(at least in theory) could this also generate problems if channels are being
changed at exactly the same time when VDR starts a recording or EPG scan is
in progress?

I can make this happen with vdr-1.3.6 + subtitles-0.1.4 + ttxtsubs-0.0.5pre2
+ streamdev-0.3.1 (on both server and on client).


					Teemu



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index