VDR developer version 1.7.17 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.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 introduces support for TrueColor OSD. Note, though, that output plugins need to be enhanced in order to support actual TrueColor display (if the device they control can handle TrueColor). Also, skins that want to make use of TrueColor may need to be adapted to the new interface using cPixmap.
The changes since version 1.7.16:
- Updated the Estonian OSD texts (thanks to Arthur Konovalov). - Fixed following symbolic links in RemoveFileOrDir() (cont'd) (thanks to Steffen Barszus). - Changed the description of cDevice::GetSTC() to make it mandatory for devices that can replay. - Removed the check for positive STC values from cDvbSubtitleConverter::Action(). - Added cString::operator=(const char *String) (suggested by Antti Seppälä). - Some spelling fixes (thanks to Ville Skyttä). - Passing package name and version to xgettext (thanks to Ville Skyttä). - Made 'dist' target dependent on up to date *.po (thanks to Ville Skyttä). - Added Language and fixed Language-Team header of *.po (thanks to Ville Skyttä). - Updated the Lithuanian OSD texts (thanks to Valdemaras Pipiras). - Fixed detecting frames on channels that broadcast with 50 or 60 fps. This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording. - Added support for "registration descriptor" to 'libsi' and using it in pat.c (thanks to Rolf Ahrenberg). - Fixed unjustified log entries about changed channel pids (reported by Derek Kelly). - Added an include of VDR's 'Make.global' to libsi's Makefile (thanks to Rolf Ahrenberg). - Removed displaying the "contents" information from the "Classic VDR" and "ST:TNG Panels" skins, because it is often wrong and nothing but irritating. - Added typecasts to avoid gcc 4.5 warnings in switch statements on eKeys variables where additional 'k_...' flags are used. - Fixed inclusion of <stdarg.h> (thanks to Henning Heinold). - Changed "frame duration" to "frame rate" in vdr.5 (reported by Tobias Grimm). - Removing a cRemote from the Remotes list in case its initialization failed (thanks to Dominik Strasser). - Added LDFLAGS to the linker calls in the Makefiles (thanks to Joerg Bornkessel and Paul Menzel). - Now updating the 'frames per second' data in the list of recordings when a new recording is started that has a frame rate other than the default. - The include path to the freetype2 header files is now retrieved via a call to 'pkg-config --cflags freetype2' (suggested by Andreas Oberritter). - The OSD now has full TrueColor support. There can be several "pixmaps" that can be overlayed with alpha blending. All existing skins should work out of the box with the TrueColor OSD - the only exception being cOsd::GetBitmap(). Since the TrueColor OSD doesn't use bitmaps, this function will return a dummy bitmap, which may not be what the plugin expects. As long as this bitmap is only used for setting the palette, there is no problem. However, any other operations on this bitmap will have no effect. See the description of the cPixmap functions in osd.h for details about the new functionalities. The "ST:TNG Panels" skin has been enhanced to automatically use the TrueColor OSD if available. The "osddemo" plugin has been extended to show some of the possibilities of the TrueColor OSD if it is run on a system that actually provides TrueColor support. Thanks to Reinhard Nissl for some valuable input, help with debugging, and an implementation of the AlphaBlend() function. - Updated the Slovakian language texts (thanks to Milan Hrala). - Added Serbian language texts (thanks to Milan Cvijanovic). - Fixed reallocating memory in the "pictures" plugin (reported by Paul Menzel, with input from Oliver Endriss). - Fixed reallocating memory in cTsToPes::PutTs() (suggested by Oliver Endriss). - Now checking the result of all realloc() calls. - Fixed setting up the 'Recordings' menu in case there are several recordings with exactly the same name (reported by Marcus Hilbrich). - Setting the audio type of language descriptors to 0x00 in the PAT/PMT generator (thanks to Anssi Hannula). - Changed the compiler optimization flag to -O3, which gives quite a performance boost in the AlphaBlend() function. - While replaying, the editing marks are now updated every 10 seconds (based on a patch from Manuel Reimer). - Now reducing the thread and I/O priority cCuttingThread::Action() to make the foreground process more responsive (suggested by Frank Neumann). - Removed checking for minimum line length of 21 characters in the LIRC receiver code (reported by Gerald Dachs). - Updated the Romanian OSD texts (thanks to Lucian Muresan). - Now storing the original display size when handling DVB subtitles (thanks to Reinhard Nissl). - The original display size of subtitles is now used to scale them properly when displaying them on an HD OSD.
Have fun!
Klaus
Al 13/03/11 12:46, En/na Klaus Schmidinger ha escrit:
This version introduces support for TrueColor OSD. Note, though, that output plugins need to be enhanced in order to support actual TrueColor display (if the device they control can handle TrueColor).
And if it cannot, will it work without modifications? What about plugins that just draw to an osd, will they work without modifications?
Bye
On 13.03.2011 14:11, Luca Olivetti wrote:
Al 13/03/11 12:46, En/na Klaus Schmidinger ha escrit:
This version introduces support for TrueColor OSD. Note, though, that output plugins need to be enhanced in order to support actual TrueColor display (if the device they control can handle TrueColor).
And if it cannot, will it work without modifications? What about plugins that just draw to an osd, will they work without modifications?
Everything should work without modifications. At least that's the plan ;-)
Klaus
On 2011-03-13 13:46, Klaus Schmidinger wrote:
- Changed the compiler optimization flag to -O3, which gives quite a performance boost in the AlphaBlend() function.
I noticed that this change was not made to Make.config.template as it should be since Make.config overrides CFLAGS and CXXFLAGS defined in Makefile.
-Matti
On 13.03.2011 14:38, Matti Lehtimäki wrote:
On 2011-03-13 13:46, Klaus Schmidinger wrote:
- Changed the compiler optimization flag to -O3, which gives quite a
performance boost in the AlphaBlend() function.
I noticed that this change was not made to Make.config.template as it should be since Make.config overrides CFLAGS and CXXFLAGS defined in Makefile.
Sorry, must have missed that one. Changed for 1.7.18.
Klaus
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:09:01 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:09:01 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:09:09 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:09:09 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:09:14 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:09:14 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:09:18 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:09:18 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode
I see there were some few changes in remux.c - any thoughts?
The only patch I've implemented in both vdr-1.7.16 and vdr-1.7.17 is as follows, to get around a problem decoding my dvb-c channels:
# diff device.c.orig device.c 1502,1513c1502,1513 < if (CamSlotNumber) { < bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; < int t = time(NULL) - startScrambleDetection; < if (Scrambled) { < if (t > TS_SCRAMBLING_TIMEOUT) < DetachReceivers = true; < } < else if (t > TS_SCRAMBLING_TIME_OK) { < DescramblingOk = true; < startScrambleDetection = 0; < } < } ---
//SBB if (CamSlotNumber) { // bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; // int t = time(NULL) - startScrambleDetection; // if (Scrambled) { // if (t > TS_SCRAMBLING_TIMEOUT) // DetachReceivers = true; // } // else if (t > TS_SCRAMBLING_TIME_OK) { // DescramblingOk = true; // startScrambleDetection = 0; // } // }
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter linuxtv@nzbaxters.com wrote:
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode
Those aren't error messages, they're just information messages from vdr-xine.
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter linuxtv@nzbaxters.com wrote:
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode
Those aren't error messages, they're just information messages from vdr-xine.
Sorry, forgot to mention - I'm getting severe video slipping. The audio sounds OK, but the video skips every few seconds as per the timestamps:
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode
Hi,
Am 14.03.2011 09:54, schrieb Simon Baxter:
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter linuxtv@nzbaxters.com wrote:
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode
Those aren't error messages, they're just information messages from vdr-xine.
Sorry, forgot to mention - I'm getting severe video slipping. The audio sounds OK, but the video skips every few seconds as per the timestamps:
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:57 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:58 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode
Looks like you're missing a patch for vdr-xine-0.9.3 to make it compatible with vdr-1.7.12. Because since that version, channels with PPID != VPID are handled differently by VDR, hence causing this issue in vdr-xine.
vdr-xine-0.9.4 will include that patch, but it will still take a few days to get it ready.
Bye.
In article 4D7CAEA2.9050109@tvdr.de you write:
VDR developer version 1.7.17 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diffWARNING:
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.
[...]
- Fixed detecting frames on channels that broadcast with 50 or 60 fps.
This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording. [...]
I wonder if I'm chasing a ghost there... am I really the only one seeing this? I can't get this index rebuilding to work regardless if I try it with old or new recordings, if I mv away the original index file that was created with a recording I always get totally different index files rebuilt (checked with hexdump/cmp -l) that cause playbacks (via xineliboutput) to look quite corrupted immediately and make vdr-sxfe hang at eof too.
This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, FreeBSD 8.2/amd64, using these ports:
http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar
(originally noticed with recordings from arte hd on 19.2E, but also reproduced with new short sd recordings, even from dvb-t.)
..and before I forget, Thanx for vdr! :) Juergen
On 17.03.2011 22:36, Juergen Lock wrote:
In article 4D7CAEA2.9050109@tvdr.de you write:
VDR developer version 1.7.17 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diffWARNING:
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.
[...]
- Fixed detecting frames on channels that broadcast with 50 or 60 fps.
This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording. [...]
I wonder if I'm chasing a ghost there... am I really the only one seeing this? I can't get this index rebuilding to work regardless if I try it with old or new recordings, if I mv away the original index file that was created with a recording I always get totally different index files rebuilt (checked with hexdump/cmp -l) that cause playbacks (via xineliboutput) to look quite corrupted immediately and make vdr-sxfe hang at eof too.
This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, FreeBSD 8.2/amd64, using these ports:
http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar
(originally noticed with recordings from arte hd on 19.2E, but also reproduced with new short sd recordings, even from dvb-t.)
I just made a recording from "arte HD" with VDR 1.7.17 and everything worked fine. It played correctly (on a TT-S2 6400 prototype), the current and total times displayed by the progress display were correct and I was able to place and move an editing mark with the picture getting updated just fine.
Klaus
In article 4D849B3A.6060308@tvdr.de you write:
On 17.03.2011 22:36, Juergen Lock wrote:
In article 4D7CAEA2.9050109@tvdr.de you write:
VDR developer version 1.7.17 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diffWARNING:
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.
[...]
- Fixed detecting frames on channels that broadcast with 50 or 60 fps.
This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording. [...]
I wonder if I'm chasing a ghost there... am I really the only one seeing this? I can't get this index rebuilding to work regardless if I try it with old or new recordings, if I mv away the original index file that was created with a recording I always get totally different index files rebuilt (checked with hexdump/cmp -l) that cause playbacks (via xineliboutput) to look quite corrupted immediately and make vdr-sxfe hang at eof too.
This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, FreeBSD 8.2/amd64, using these ports:
http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar
(originally noticed with recordings from arte hd on 19.2E, but also reproduced with new short sd recordings, even from dvb-t.)
I just made a recording from "arte HD" with VDR 1.7.17 and everything worked fine. It played correctly (on a TT-S2 6400 prototype), the current and total times displayed by the progress display were correct and I was able to place and move an editing mark with the picture getting updated just fine.
So it also works when you stop vdr, mv the recording's index file away and then let vdr regenerate it? Could this be an amd64/x86_64 issue?
Thanx, Juergen
On 19.03.2011 16:19, Juergen Lock wrote:
In article 4D849B3A.6060308@tvdr.de you write:
On 17.03.2011 22:36, Juergen Lock wrote:
In article 4D7CAEA2.9050109@tvdr.de you write:
VDR developer version 1.7.17 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diffWARNING:
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.
[...]
- Fixed detecting frames on channels that broadcast with 50 or 60 fps.
This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording. [...]
I wonder if I'm chasing a ghost there... am I really the only one seeing this? I can't get this index rebuilding to work regardless if I try it with old or new recordings, if I mv away the original index file that was created with a recording I always get totally different index files rebuilt (checked with hexdump/cmp -l) that cause playbacks (via xineliboutput) to look quite corrupted immediately and make vdr-sxfe hang at eof too.
This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, FreeBSD 8.2/amd64, using these ports:
http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar
(originally noticed with recordings from arte hd on 19.2E, but also reproduced with new short sd recordings, even from dvb-t.)
I just made a recording from "arte HD" with VDR 1.7.17 and everything worked fine. It played correctly (on a TT-S2 6400 prototype), the current and total times displayed by the progress display were correct and I was able to place and move an editing mark with the picture getting updated just fine.
So it also works when you stop vdr, mv the recording's index file away and then let vdr regenerate it?
Yes, it does.
Could this be an amd64/x86_64 issue?
Maybe, I don't know.
Klaus
In article 201103191519.p2JFJKZw037553@triton8.kn-bremen.de you write:
In article 4D849B3A.6060308@tvdr.de you write:
On 17.03.2011 22:36, Juergen Lock wrote:
In article 4D7CAEA2.9050109@tvdr.de you write:
VDR developer version 1.7.17 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diffWARNING:
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.
[...]
- Fixed detecting frames on channels that broadcast with 50 or 60 fps.
This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording. [...]
I wonder if I'm chasing a ghost there... am I really the only one seeing this? I can't get this index rebuilding to work regardless if I try it with old or new recordings, if I mv away the original index file that was created with a recording I always get totally different index files rebuilt (checked with hexdump/cmp -l) that cause playbacks (via xineliboutput) to look quite corrupted immediately and make vdr-sxfe hang at eof too.
This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, FreeBSD 8.2/amd64, using these ports:
http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar
(originally noticed with recordings from arte hd on 19.2E, but also reproduced with new short sd recordings, even from dvb-t.)
I just made a recording from "arte HD" with VDR 1.7.17 and everything worked fine. It played correctly (on a TT-S2 6400 prototype), the current and total times displayed by the progress display were correct and I was able to place and move an editing mark with the picture getting updated just fine.
So it also works when you stop vdr, mv the recording's index file away and then let vdr regenerate it? Could this be an amd64/x86_64 issue?
Found the problem: The FreeBSD patches disable USE_FADVISE in tools.c, and there was an #else clause missing when its not defined:
--- tools.c.orig +++ tools.c @@ -1669,6 +1669,9 @@ ssize_t cUnbufferedFile::Read(void *Data } } lastpos = curpos; +#else + if (bytesRead > 0) + curpos += bytesRead; #endif return bytesRead; }
There is one remaining bug tho: After playback of a short recording (sd in this case, 20s or so), vdr seems to kind of hang and I have to kill it... Can you reproduce that? Longer recordings are not affected.
Thanx, :) Juergen
Am 19.03.2011 18:40, schrieb Juergen Lock:
There is one remaining bug tho: After playback of a short recording (sd in this case, 20s or so), vdr seems to kind of hang and I have to kill it... Can you reproduce that? Longer recordings are not affected.
This is probably an old bug: For me, VDR has always been hanging at the end of a recording, if that recording is shorter than one minute. Takes 10 or 20 seconds, then brings you back to live view again. Its not that annoying, as recordings are usually longer, so I've never been going on bug hunt for this.
Cheers,
Udo
In article 4D84EE1D.8090503@gmx.de you write:
Am 19.03.2011 18:40, schrieb Juergen Lock:
There is one remaining bug tho: After playback of a short recording (sd in this case, 20s or so), vdr seems to kind of hang and I have to kill it... Can you reproduce that? Longer recordings are not affected.
This is probably an old bug: For me, VDR has always been hanging at the end of a recording, if that recording is shorter than one minute. Takes 10 or 20 seconds, then brings you back to live view again. Its not that annoying, as recordings are usually longer, so I've never been going on bug hunt for this.
Ah yeah, that could well be it. I also found that sometimes playback of a short recording that was played before(?) doesn't start until you hit green... (black screen or `no signal', don't remember.)
Anyway, you are right, short recordings are kinda rare in real life. :)
Thanx, Juergen
Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
- While replaying, the editing marks are now updated every 10 seconds (based on a patch from Manuel Reimer).
Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I only used the marks reloading. (As a good-bye, I've posted an updated jumpplay at [1]).
However, the VDR version also has the slow update speed of once every 10 seconds that I don't like. Especially after editing, I usually immediately switch to the edited recording to check the result, and then have to either wait 10 seconds for all marks to appear, or re-start the replay to get updated marks. (With hard link cutter, editing is usually done in less than 10 seconds.)
As a solution, I thought it would be a good idea to reload the marks file whenever the index file gets updated. Unfortunately, this is more complicated than I thought, because the marks reside in cReplayControl, while the index is in a cDvbPlayer which is owned by cDvbPlayerControl. There is no direct access to the index from cReplayControl.
Polling for number of total frames via GetIndex() would work, as cReplayControl::ShowProgress does - but only if the editing OSD is visible. So add another polling of GetIndex(), and another lastTotal to check for changes? Not very elegant. The alternative would be some extra rewrites...
Any thoughts on that?
Cheers,
Udo
[1] http://www.vdr-portal.de/board/thread.php?threadid=104863
On 19.03.2011 21:56, Udo Richter wrote:
Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
- While replaying, the editing marks are now updated every 10 seconds (based on a patch from Manuel Reimer).
Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I only used the marks reloading. (As a good-bye, I've posted an updated jumpplay at [1]).
However, the VDR version also has the slow update speed of once every 10 seconds that I don't like. Especially after editing, I usually immediately switch to the edited recording to check the result, and then have to either wait 10 seconds for all marks to appear, or re-start the replay to get updated marks. (With hard link cutter, editing is usually done in less than 10 seconds.)
As a solution, I thought it would be a good idea to reload the marks file whenever the index file gets updated. Unfortunately, this is more complicated than I thought, because the marks reside in cReplayControl, while the index is in a cDvbPlayer which is owned by cDvbPlayerControl. There is no direct access to the index from cReplayControl.
Polling for number of total frames via GetIndex() would work, as cReplayControl::ShowProgress does - but only if the editing OSD is visible. So add another polling of GetIndex(), and another lastTotal to check for changes? Not very elegant. The alternative would be some extra rewrites...
Any thoughts on that?
How about taking the age of the marks file into account? Like, when checking whether the file has been changed, calculate the age of the file (tm) and schedule the next check for "now + f(tm)". That way, a file that has just been updated will be checked again very soon, while an old file will only be checked rarely. Ages under one minute could be treated as "one second", ages under one hour as "10 seconds" and anything older could just result in not rereading the marks file (since it's rather unlikely that it will change once it's grown that old).
Klaus
On 19.03.2011 22:42, Klaus Schmidinger wrote:
On 19.03.2011 21:56, Udo Richter wrote:
Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
- While replaying, the editing marks are now updated every 10 seconds (based on a patch from Manuel Reimer).
Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I only used the marks reloading. (As a good-bye, I've posted an updated jumpplay at [1]).
However, the VDR version also has the slow update speed of once every 10 seconds that I don't like. Especially after editing, I usually immediately switch to the edited recording to check the result, and then have to either wait 10 seconds for all marks to appear, or re-start the replay to get updated marks. (With hard link cutter, editing is usually done in less than 10 seconds.)
As a solution, I thought it would be a good idea to reload the marks file whenever the index file gets updated. Unfortunately, this is more complicated than I thought, because the marks reside in cReplayControl, while the index is in a cDvbPlayer which is owned by cDvbPlayerControl. There is no direct access to the index from cReplayControl.
Polling for number of total frames via GetIndex() would work, as cReplayControl::ShowProgress does - but only if the editing OSD is visible. So add another polling of GetIndex(), and another lastTotal to check for changes? Not very elegant. The alternative would be some extra rewrites...
Any thoughts on that?
How about taking the age of the marks file into account? Like, when checking whether the file has been changed, calculate the age of the file (tm) and schedule the next check for "now + f(tm)". That way, a file that has just been updated will be checked again very soon, while an old file will only be checked rarely. Ages under one minute could be treated as "one second", ages under one hour as "10 seconds" and anything older could just result in not rereading the marks file (since it's rather unlikely that it will change once it's grown that old).
I have attached a patch that implements this. Would this be ok?
Klaus
On 20.03.2011 12:46, Klaus Schmidinger wrote:
On 19.03.2011 22:42, Klaus Schmidinger wrote:
On 19.03.2011 21:56, Udo Richter wrote:
Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
- While replaying, the editing marks are now updated every 10 seconds (based on a patch from Manuel Reimer).
Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I only used the marks reloading. (As a good-bye, I've posted an updated jumpplay at [1]).
However, the VDR version also has the slow update speed of once every 10 seconds that I don't like. Especially after editing, I usually immediately switch to the edited recording to check the result, and then have to either wait 10 seconds for all marks to appear, or re-start the replay to get updated marks. (With hard link cutter, editing is usually done in less than 10 seconds.)
As a solution, I thought it would be a good idea to reload the marks file whenever the index file gets updated. Unfortunately, this is more complicated than I thought, because the marks reside in cReplayControl, while the index is in a cDvbPlayer which is owned by cDvbPlayerControl. There is no direct access to the index from cReplayControl.
Polling for number of total frames via GetIndex() would work, as cReplayControl::ShowProgress does - but only if the editing OSD is visible. So add another polling of GetIndex(), and another lastTotal to check for changes? Not very elegant. The alternative would be some extra rewrites...
Any thoughts on that?
How about taking the age of the marks file into account? Like, when checking whether the file has been changed, calculate the age of the file (tm) and schedule the next check for "now + f(tm)". That way, a file that has just been updated will be checked again very soon, while an old file will only be checked rarely. Ages under one minute could be treated as "one second", ages under one hour as "10 seconds" and anything older could just result in not rereading the marks file (since it's rather unlikely that it will change once it's grown that old).
I have attached a patch that implements this. Would this be ok?
Sorry, there was a line missing that makes sure the initial load takes place. Attached is a revised version of the patch.
Klaus
Am 20.03.2011 13:31, schrieb Klaus Schmidinger:
On 20.03.2011 12:46, Klaus Schmidinger wrote:
I have attached a patch that implements this. Would this be ok?
Sorry, there was a line missing that makes sure the initial load takes place. Attached is a revised version of the patch.
You're too fast for me.... :D
I like the general idea, but I have some points about it: - Disappearing marks or replacing marks by older versions is not detected. - Double updates within one second may get lost. - I don't think that it hurts to poll every 10 seconds, so IMHO we can drop the 3600s check. - When in pause mode with the progress bar on OSD, the OSD doesn't get updated when the marks get reloaded.
After some iterations I've ended with the attached patch that fixes the first two issues, and is less messy with lastFileTime. Any change of file time will be detected, and the new lastChange covers cases where no marks file is present. There's a small gap with the lastFileTime == t check on NFS volumes with unsynced clocks, but thats another story.
The third point is a matter of taste, and the fourth is not that important.
Cheers,
Udo
On 20.03.2011 21:07, Udo Richter wrote:
Am 20.03.2011 13:31, schrieb Klaus Schmidinger:
On 20.03.2011 12:46, Klaus Schmidinger wrote:
I have attached a patch that implements this. Would this be ok?
Sorry, there was a line missing that makes sure the initial load takes place. Attached is a revised version of the patch.
You're too fast for me.... :D
I like the general idea, but I have some points about it:
- Disappearing marks or replacing marks by older versions is not detected.
Ok, that would be the
if (LastModified != lastFileTime)
change, agreed.
- Double updates within one second may get lost.
- I don't think that it hurts to poll every 10 seconds, so IMHO we can
drop the 3600s check.
I'd still like to phase that out, because for such old marks files it just doesn't make sense to poll them any more.
- When in pause mode with the progress bar on OSD, the OSD doesn't get
updated when the marks get reloaded.
After some iterations I've ended with the attached patch that fixes the first two issues, and is less messy with lastFileTime. Any change of file time will be detected, and the new lastChange covers cases where no marks file is present. There's a small gap with the lastFileTime == t check on NFS volumes with unsynced clocks, but thats another story.
The third point is a matter of taste, and the fourth is not that important.
Can you please rewrite your patch so that it keeps the original 'd' variable? I liked the fact that the 'nextUpdate' variable was incremented in *one* place, and not in several places. Made the whole thing more transparent to me. Besides, I could then see what you have *actually* changed ;-)
Klaus
Am 27.03.2011 16:45, schrieb Klaus Schmidinger:
Can you please rewrite your patch so that it keeps the original 'd' variable? I liked the fact that the 'nextUpdate' variable was incremented in *one* place, and not in several places. Made the whole thing more transparent to me. Besides, I could then see what you have *actually* changed ;-)
Another example on how coding style is a matter of taste. One of the first things I changed was the removing of the d variable that is IMHO superfluous, doesn't have an unique meaning (file age in seconds and time to next check), and no descriptive name. ;)
Anyway, I've rewritten it to match your original patch more closely. Actually I'm surprised how similar they got again, I had some evolution steps that were completely different.
Attached is the rewritten patch as updatemarks-4, and for your convenience a diff between updatemarks-2 and updatemarks-4 that shows the differences more closely.
Cheers,
Udo
-
Juergen Lock -
Klaus Schmidinger -
Luca Olivetti -
Matti Lehtimäki -
Reinhard Nissl -
Simon Baxter -
Udo Richter -
VDR User