VDR developer version 1.7.20 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.20.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.19-1.7.20.diff
MD5 checksums:
eda2911fff1715ba5b1482b20ad18188 vdr-1.7.20.tar.bz2 a8f5bcaf3294cc9fce87283a618d5ce1 vdr-1.7.19-1.7.20.diff
WARNING: ========
This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
This version contains functions to determine the "signal strength" and "signal quality" through cDevice. If you are using a DVB card that contains an stb0899 frontend chip (like the TT-budget S2-3200) you may want to apply the patches from
ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches
to the LinuxDVB driver source in order to receive useful results from that frontend.
The changes since version 1.7.19:
- Added some missing 'const' to tChannelID (reported by Sundararaj Reel). - The isnumber() function now checks the given pointer for NULL (thanks to Holger Dengler). - Now checking Setup.InitialChannel for NULL before using it (reported by Christoph Haubrich). - cSkins::Message() now blocks calls from background threads (thanks to Michael Eiler for reporting a crash in such a scenario). - Fixed the return value of the svdrpsend.pl script in case of an error (thanks to Jonas Diemer). - Increased MAXCAIDS to 12 (thanks to Jerome Lacarriere). - Fixed handling DiSEqC codes (thanks to Mark Hawes for reporting the bug, and Udo Richter for suggesting the fix). - Added a mechanism to defer timer handling in case of problems (reported by Frank Niederwipper). - Fixed distortions that happened when splitting recording into several files (was a side effect of "Fixed detecting frames in case the Picture Start Code or Access Unit Delimiter extends over TS packet boundaries" in version 1.7.19). cRecorder::Action() now buffers TS packets in case the frame type is not yet known when a new payload starts. This adds no overhead for channels that broadcast the frame type within the first TS packet of a payload; it only kicks in if that information is not in the first TS packet. - Fixed handling the channelID in cMenuEditChanItem (thanks to Udo Richter). - cStringList::Sort() can now be called with a boolean parameter that controls case insensitive sorting (suggested by Sundararaj Reel). - Now scanning new transponders before old ones, to make sure transponder changes are recognized (thanks to Reinhard Nissl). - Implemented static cIndexFile::IndexFileName(). - The length (as number of frames) of a recording's index file can now be determined by a call to cIndexFile::GetLength() (suggested by Christoph Haubrich). - Fixed some crashes in subtitle display (thanks to Rolf Ahrenberg). - Made DELETENULL() thread safe (reported by Rolf Ahrenberg). - The pic2mpg script of the 'pictures' plugin now generates HD images (thanks to Andre Weidemann for his support in using convert/ffmpeg). The old SD version is still available as pic2mpg-sd. - Added a mutex to protect cOsd::Osds from simultaneous access from different threads (reported by Rolf Ahrenberg). - The cutter now sets the 'broken link' flag for MPEG2 TS recordings (thanks to Oliver Endriss). - Fixed language code entry for Portuguese. - The new command line options --filesize (suggested by Marco Göbenich) and --split can be used together with --edit to set the maximum video file size and turn on splitting edited files at the editing marks. These options must be given before --edit to have an effect. - cTimeMs is no longer initialized to the current time if the value given to the constructor is negative (avoids the "cTimeMs: using monotonic clock..." log message before VDR's starting log message).
Have fun!
Klaus
Am 16.08.2011 18:57, schrieb Klaus Schmidinger:
VDR developer version 1.7.20 is now available at
Thanks for the new version - at a surprising time. ;)
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.20.tar.bz2
Just a note: The tar file includes a 0-byte epg.data file and an empty themes sub-folder.
Unfortunately, this will break the osdserver-plugin, that does call these directly from the network interface thread - though not without first locking the main thread in a safe state.
I'll see if I can work around this, or if I can come up with some other solution.
Cheers,
Udo
Am 16.08.2011 23:13, schrieb Klaus Schmidinger:
Sure, however QueueMessage does not wait and does not return an user key press. Osdserver exports all of the message functions, including QueueMessage.
I'll probably solve this by a main thread callback, some other parts of OsdServer do this already.
A solution / extension on VDR side would be to replace the 'main thread' concept with a 'big VDR lock': A global lock that the main thread releases just before sleeping, and re-locks after waking up. That way, any background thread could use that lock to trap the main thread safely, and use all of the not thread safe parts of VDR that previously were only safely available to the main thread.
I think the kernel guys have a big lock they don't use any more, maybe we can get that one. ;)
Cheers,
Udo
On 19.08.2011 20:48, Udo Richter wrote:
That's by design ;-) A background thread is not supposed to do this!
Osdserver exports all of the message functions, including QueueMessage.
Well, I guess it shouldn't.
The kernel developers only recently got rid of this, and they had good reasons to do so, I guess. I wouldn't want to do that in VDR.
Klaus
On Sat, Aug 20, 2011 at 12:16:01PM +0200, Klaus Schmidinger wrote:
The general reason kernels get a big (or "giant") lock is when adding smp support (more than one cpu, i.e. more than one thread can be running at a time so suddenly there's need for locking in a lot more places.) The reason that big lock is removed later (actually pushed out to different individual locks) is only to improve smp performance (less time spent waiting on a single lock), which I guess an userland app like vdr would have less reason to worry about.
Just thought I'd mention... :) Juergen
Am 20.08.2011 12:16, schrieb Klaus Schmidinger:
Osdserver has no other choice. From the main thread, Osdserver could only react once a second, meaning that an average osdserver menu would need 30 seconds to appear. Thus, a completely backgrounded network thread is a must.
Osdserver solves this with some complex own locking mechanisms, dirty tricks to force a wakeup of the VDR main thread, and threadsafe shadow copies of non-threadsafe data structures. A global lock would make things a lot easier.
Would mean, osdserver clients cannot do a simple yes/no query. Not an option.
The kernel developers only recently got rid of this, and they had good reasons to do so, I guess. I wouldn't want to do that in VDR.
You're free to implement a fine-grained locking for all non-threadsafe data structures, like the kernel guys did, but IMHO one big lock is better than none. ;)
Anyway, Osdserver is fixed now, and uses a callback from MainThreadHook to do the Skins.Message() call.
Cheers,
Udo
-
Albert Gall -
Juergen Lock -
Klaus Schmidinger -
Udo Richter