Hi.
When I use FF (fast forward 1-3x) when playing a recording, VDR stalls. Sometimes, after several minutes, it will recover. Most of the time I'm just left with a frozen frame.
The 60-second skip forward or back works fine.
Any ideas how to diagnose this problem?
Hi, I have problem with burn-0.0.6e plugin.Sometime the dvd creation process fail. I try other different version of vdrsync.pl but I have the same problem or the plugin doesn't work. It's a vdrsync.pl problem or not? Below you can find my log.
Thank's Rudy.
This is my system log: Jun 11 14:10:53 Vdrbox logger: Starting <nice -n 19 vdrsync.pl -cut -o /video/.vdr-burn.yvgsjK/VDRSYNC.2 /video/Un_paso_adelante/I_preparativi_di_hair/2005-05-26.14:35.50.99.rec> Jun 11 14:10:54 Vdrbox vdr[11407]: BURN: Subprocess watcher stopped
And this my dvd.log:
++ started: sh -c 'vdrburn.sh SYNC '/video/.vdr-burn.yvgsjK' 2 '/video/Un_paso_adelante/I_preparativi_di_hair/2005-05-26.14:35.50.99.rec'' logger: <SYNC /video/.vdr-burn.yvgsjK 2 /video/Un_paso_adelante/I_preparativi_di_hair/2005-05-26.14:35.50.99.rec> + '[' SYNC = SYNC ']' + '[' yes == yes ']' + CUTCMD=-cut + ExecCmd vdrsync.pl -cut -o /video/.vdr-burn.yvgsjK/VDRSYNC.2 /video/Un_paso_adelante/I_preparativi_di_hair/2005-05-26.14:35.50.99.rec + logger -s 'Starting <nice -n 19 vdrsync.pl -cut -o /video/.vdr-burn.yvgsjK/VDRSYNC.2 /video/Un_paso_adelante/I_preparativi_di_hair/2005-05-26.14:35.50.99.rec>' logger: Starting <nice -n 19 vdrsync.pl -cut -o /video/.vdr-burn.yvgsjK/VDRSYNC.2 /video/Un_paso_adelante/I_preparativi_di_hair/2005-05-26.14:35.50.99.rec> + nice -n 19 vdrsync.pl -cut -o /video/.vdr-burn.yvgsjK/VDRSYNC.2 /video/Un_paso_adelante/I_preparativi_di_hair/2005-05-26.14:35.50.99.rec Parameter validation not complete yet Initialising and analysing the streams.... **************************************** READING INDEX FILE, please be patient **************************************** Got only 57996, you wanted 57985 and last IFrame is 57984... Got only 57996, you wanted 57985 and last IFrame is 57984... Got only 57996, you wanted 57997 and last IFrame is 57984... Got only 57996, you wanted 57997 and last IFrame is 57984... Got only 57996, you wanted 57985 and last IFrame is 57984... Got only 57996, you wanted 57997 and last IFrame is 57984... Got only 57996, you wanted 57997 and last IFrame is 57984... Got only 57996, you wanted 57997 and last IFrame is 57984... Got only 57996, you wanted 57997 and last IFrame is 57984... Got only 57996, you wanted 57985 and last IFrame is 57984... Got only 57996, you wanted 57985 and last IFrame is 57984...
0 Mbytes of 0 read 314 PES packets processed Use of uninitialized value in numeric gt (>) at /usr/bin/vdrsync.pl line 4118. Use of uninitialized value in concatenation (.) or string at /usr/bin/vdrsync.pl line 4121. Not changing current_last_pts cause is equal to 0 This is not supposed to happen!
Rudy Sgorlon wrote:
I have problem with burn-0.0.6e plugin.
Where does burn-0.0.6e come from? Is http://www.xeatre.de/community/burn no longer the official site with the latest version? On that site, there still only is 0.0.5.
Carsten.
From here: http://vdr.unetz.com/download/
Rudy.
Carsten Koch ha scritto:
Rudy Sgorlon wrote:
I have problem with burn-0.0.6e plugin.
Where does burn-0.0.6e come from? Is http://www.xeatre.de/community/burn no longer the official site with the latest version? On that site, there still only is 0.0.5.
Carsten.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Rudy Sgorlon wrote:
From here: http://vdr.unetz.com/download
Thanks!
Carsten Koch ha scritto:
...
Where does burn-0.0.6e come from? Is http://www.xeatre.de/community/burn no longer the official site with the latest version?
When I use FF (fast forward 1-3x) when playing a recording, VDR stalls. Sometimes, after several minutes, it will recover. Most of the time I'm just left with a frozen frame.
The 60-second skip forward or back works fine.
Any ideas how to diagnose this problem?
No tips from me, but using vdr-1.3.20 and vdr-xine 7.3, i have given up trying to FF & RR acuratly. I now just use 60 second skip. But I would *love* to be able to edit my recordings.. I've never been able to FF/RR as this is my first install..
Mick
mike lewis wrote:
When I use FF (fast forward 1-3x) when playing a recording, VDR stalls. Sometimes, after several minutes, it will recover. Most of the time I'm just left with a frozen frame.
The 60-second skip forward or back works fine.
Any ideas how to diagnose this problem?
No tips from me, but using vdr-1.3.20 and vdr-xine 7.3, i have given up trying to FF & RR acuratly. I now just use 60 second skip. But I would *love* to be able to edit my recordings.. I've never been able to FF/RR as this is my first install..
Mick
vdr-xine-0.7.2 is the last version, where FF/RR works since 0.7.3 it's broken Jörg
Hi,
Joerg Riechardt wrote:
When I use FF (fast forward 1-3x) when playing a recording, VDR stalls. Sometimes, after several minutes, it will recover. Most of the time I'm just left with a frozen frame.
The 60-second skip forward or back works fine.
Any ideas how to diagnose this problem?
No tips from me, but using vdr-1.3.20 and vdr-xine 7.3, i have given up trying to FF & RR acuratly. I now just use 60 second skip. But I would *love* to be able to edit my recordings.. I've never been able to FF/RR as this is my first install..
vdr-xine-0.7.2 is the last version, where FF/RR works since 0.7.3 it's broken
Well, there's changed quite a lot in 0.7.3. Just to make things clear:
FF = fast forward SF = slow forward FR = fast reverse (rewind) SR = slow reverse (rewind)
FF, FR and SR as well as moving cutting marks just play I-frames and there is a problem in VDR that sends incomplete I-frames to the devices. Especially when xine reports bad_frame on its controlling terminal then it is likely that the "bug" triggered.
http://home.vr-web.de/~rnissl/vdr-1.3.24-dvbplayer.patch
addresses this issue. A proper solution will be supplied by cVideoRepacker but it seems to trigger other problems so it is disabled in recent VDR versions. The above patch will then still be necessary to edit old recordings properly which have been recorded without cVideoRepacker.
A known issue is that switching from pause or play to any of the above mentioned speeds will cause a delay of several seconds before playback at the new speed gets active. This issue is most noticeable on less powerful machines like my EPIA MII-6000E which has just a 600 MHz CPU, while it is not that much noticeable on my development PC which has a Pentium 4 HT processor which runs at 2.8 GHz.
To let me address your issue properly, would you please explain whether one of the above issues is what you experience or if it is a new issue.
Bye.
Reinhard Nissl wrote:
Hi,
Joerg Riechardt wrote:
When I use FF (fast forward 1-3x) when playing a recording, VDR stalls. Sometimes, after several minutes, it will recover. Most of the time I'm just left with a frozen frame.
The 60-second skip forward or back works fine.
Any ideas how to diagnose this problem?
No tips from me, but using vdr-1.3.20 and vdr-xine 7.3, i have given up trying to FF & RR acuratly. I now just use 60 second skip. But I would *love* to be able to edit my recordings.. I've never been able to FF/RR as this is my first install..
vdr-xine-0.7.2 is the last version, where FF/RR works since 0.7.3 it's broken
Well, there's changed quite a lot in 0.7.3. Just to make things clear:
FF = fast forward SF = slow forward FR = fast reverse (rewind) SR = slow reverse (rewind)FF, FR and SR as well as moving cutting marks just play I-frames and there is a problem in VDR that sends incomplete I-frames to the devices. Especially when xine reports bad_frame on its controlling terminal then it is likely that the "bug" triggered.
http://home.vr-web.de/~rnissl/vdr-1.3.24-dvbplayer.patchaddresses this issue. A proper solution will be supplied by cVideoRepacker but it seems to trigger other problems so it is disabled in recent VDR versions. The above patch will then still be necessary to edit old recordings properly which have been recorded without cVideoRepacker.
A known issue is that switching from pause or play to any of the above mentioned speeds will cause a delay of several seconds before playback at the new speed gets active. This issue is most noticeable on less powerful machines like my EPIA MII-6000E which has just a 600 MHz CPU, while it is not that much noticeable on my development PC which has a Pentium 4 HT processor which runs at 2.8 GHz.
To let me address your issue properly, would you please explain whether one of the above issues is what you experience or if it is a new issue.
Bye.
The delay (quite long on my Celeron 1300) is from play to FF or FR. I have the vdr-1.3.24-dvbplayer.patch applied. So it's the known issue. Since FF and FR is essential for me, I stayed with 0.7.2.
Jörg
To let me address your issue properly, would you please explain whether one of the above issues is what you experience or if it is a new issue.
I upgraded to 0.7.4 and vdr-1.3.27, and applied the suggested patch last night. I am happy to report that I can now edit my recordings satisfactorily. I only noticed one issue: when jumping between marks, vdr pauses and when you try to play, vdr plays from from where you left off, not from the mark you are on. Not sure if this is a bug or a user issue; but i'm a much happier user now ;-).
Mick
It's not just you Mick. I too have the same results - I can now FF and REW ok with vdr-1.3.27 and vdr-xine-0.7.4, but moving between marks doesn't work properly.
I can't skip between marks properly, and when I try to move the marks (6 and 4) it doesn't scan the clip. Did you find this too? ----- Original Message ----- From: "mike lewis" lachlanlewis@gmail.com To: "Klaus Schmidinger's VDR" vdr@linuxtv.org Sent: Monday, July 04, 2005 5:30 AM Subject: Re: [vdr] vdr-xine FF & RW stall
To let me address your issue properly, would you please explain whether one of the above issues is what you experience or if it is a new issue.
I upgraded to 0.7.4 and vdr-1.3.27, and applied the suggested patch last night. I am happy to report that I can now edit my recordings satisfactorily. I only noticed one issue: when jumping between marks, vdr pauses and when you try to play, vdr plays from from where you left off, not from the mark you are on. Not sure if this is a bug or a user issue; but i'm a much happier user now ;-).
Mick
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Simon Baxter wrote:
It's not just you Mick. I too have the same results - I can now FF and REW ok with vdr-1.3.27 and vdr-xine-0.7.4, but moving between marks doesn't work properly.
I can't skip between marks properly, and when I try to move the marks (6 and 4) it doesn't scan the clip. Did you find this too?
Hhm, due to development of cVideoRepacker I'm still stuck with vdr-1.3.25. Would you please try 1.3.25 and report your results?
Can you supply me a link to a small recording (5 ~ 10 MB) which shows this issue?
Was this recording taken prior to VDR-1.3.26, i. e. without cVideoRepacker?
Did you enable cVideoRepacker in VDR-1.3.27?
cVideoRepacker will finally make my patch only necessary to edit old recordings, but the patch should not be harmful to any recordings taken with cVideoRepacker enabled (= my current setup).
At the moment, the patch is still necessary for recordings taken with cVideoRepacker as VDR lacks adding the end of sequence marker to still images. As a result you wouldn't see the image changing while moving cutting marks. This will be addressed in VDR-1.3.28, as time permits.
Bye.
It's not just you Mick. I too have the same results - I can now FF and REW ok with vdr-1.3.27 and vdr-xine-0.7.4, but moving between marks doesn't work properly.
I can't skip between marks properly, and when I try to move the marks (6 and 4) it doesn't scan the clip. Did you find this too?
Hhm, due to development of cVideoRepacker I'm still stuck with vdr-1.3.25. Would you please try 1.3.25 and report your results?
Can you supply me a link to a small recording (5 ~ 10 MB) which shows this issue?
Will do some test recordings tonight
Was this recording taken prior to VDR-1.3.26, i. e. without cVideoRepacker?
Did you enable cVideoRepacker in VDR-1.3.27?
cVideoRepacker is in remux.c from vdr-1.3.26 no? Originally, the recording was done pre-cVideoRepacker on version 1.3.23 and played under 1.3.27.
cVideoRepacker will finally make my patch only necessary to edit old recordings, but the patch should not be harmful to any recordings taken with cVideoRepacker enabled (= my current setup).
I've not applied any patches - just used the stock vdr-1.3.27
At the moment, the patch is still necessary for recordings taken with cVideoRepacker as VDR lacks adding the end of sequence marker to still images. As a result you wouldn't see the image changing while moving cutting marks. This will be addressed in VDR-1.3.28, as time permits.
Great, thanks.
Simon
Hi,
Simon Baxter wrote:
Was this recording taken prior to VDR-1.3.26, i. e. without cVideoRepacker?
Did you enable cVideoRepacker in VDR-1.3.27?
cVideoRepacker is in remux.c from vdr-1.3.26 no?
In VDR-1.3.26, cVideoRepacker was active by default.
cVideoRepacker will finally make my patch only necessary to edit old recordings, but the patch should not be harmful to any recordings taken with cVideoRepacker enabled (= my current setup).
I've not applied any patches - just used the stock vdr-1.3.27
Hhm, that doesn't work properly then. For vdr-xine-0.7.4, you'll need my dvbplayer-patch which is available on my homepage.
Bye.
On Fri, 2005-07-08 at 13:18 +0200, Reinhard Nissl wrote:
cVideoRepacker will finally make my patch only necessary to edit old recordings, but the patch should not be harmful to any recordings taken with cVideoRepacker enabled (= my current setup).
I've not applied any patches - just used the stock vdr-1.3.27
Hhm, that doesn't work properly then. For vdr-xine-0.7.4, you'll need my dvbplayer-patch which is available on my homepage.
To add some more information to this discussion...
I was using vdr-1.3.25 with xine-0.7.4 and I was getting pauses of about 2 s or so between stopping ffwd and replay starting again. It was also difficult to go back or forward accurately because what was shown during ffwd or rwd seemed to be several seconds out from where it stopped!
I have just upgraded to vdr-1.3.27 with cVideoRepacker enabled and dvbplayer patched with xine-0.7.4 and it seems much more responsive. Multi-speed works although I don't think the picture updates during ffwd until I get to full-speed. Slow motion also works forward; I think I tried going backwards slowly and vdr restarted.
This was only a quick test but this seems much better than it was with my previous version.
Cheers,
Laz
Was this recording taken prior to VDR-1.3.26, i. e. without cVideoRepacker?
Did you enable cVideoRepacker in VDR-1.3.27?
cVideoRepacker is in remux.c from vdr-1.3.26 no?
In VDR-1.3.26, cVideoRepacker was active by default.
cVideoRepacker will finally make my patch only necessary to edit old recordings, but the patch should not be harmful to any recordings taken with cVideoRepacker enabled (= my current setup).
I've not applied any patches - just used the stock vdr-1.3.27
Hhm, that doesn't work properly then. For vdr-xine-0.7.4, you'll need my dvbplayer-patch which is available on my homepage.
I applied the dvbplayer-patch and can now 'scan' the marks in edit mode.
I still have a 2-10 second delay when FF or REW in playback mode though. Have to use the 60-second forward or back buttons.
....incidentally, is there any way to change the 60-second jump to 30 instead??
Hi,
Simon Baxter wrote:
I've not applied any patches - just used the stock vdr-1.3.27
Hhm, that doesn't work properly then. For vdr-xine-0.7.4, you'll need my dvbplayer-patch which is available on my homepage.
I applied the dvbplayer-patch and can now 'scan' the marks in edit mode.
Fine.
I still have a 2-10 second delay when FF or REW in playback mode though. Have to use the 60-second forward or back buttons.
This is the known issue. But I must admit, that I currently don't have any idea how it is caused.
....incidentally, is there any way to change the 60-second jump to 30 instead??
This value is hardcoded, see menu.c:
case kGreen|k_Repeat: case kGreen: SkipSeconds(-60); break; case kYellow|k_Repeat: case kYellow: SkipSeconds( 60); break;
Personally, I've added that the key 1/3 skips back/forward 10 seconds. But the two keys are intended to be used differently. That's way my patch didn't make it into VDR yet.
Bye.
Personally, I've added that the key 1/3 skips back/forward 10 seconds. But the two keys are intended to be used differently. That's way my patch didn't make it into VDR yet.
My Hauppauge grey remote has 2 'skip' keys which I'm not using with VDR labelled |< and >| They generate the following codes: 21:54:37.905822: EV_KEY KEY_NEXT pressed 21:54:38.153125: EV_KEY KEY_NEXT released and 21:54:39.577622: EV_KEY KEY_PREVIOUS pressed 21:54:39.824925: EV_KEY KEY_PREVIOUS released
how can I incorporate these? -which VDR module controls which keys are learnt (when no remote.conf exists). I think if I can understand how the mappings are related into 'kRecord, kFastFwd, kFastRew, k1' etc I should be ok
--------------------------------------------------------------------------------
--- ../vdr-1.3.25-orig/keys.h 2004-12-27 12:10:59.000000000 +0100 +++ keys.h 2005-01-09 18:24:11.000000000 +0100 @@ -65,6 +65,8 @@ enum eKeys { // "Up" and "Down" must be #define kMarkJumpForward k9 #define kEditCut k2 #define kEditTest k8 +#define kEditJumpBack k1 +#define kEditJumpForward k3
#define RAWKEY(k) (eKeys((k) & ~k_Flags)) #define ISRAWKEY(k) ((k) != kNone && ((k) & k_Flags) == 0) --- ../vdr-1.3.25-orig/menu.c 2005-05-16 15:59:03.000000000 +0200 +++ menu.c 2005-05-29 18:52:42.000000000 +0200 @@ -3723,6 +3742,10 @@ eOSState cReplayControl::ProcessKey(eKey case kMarkMoveForward: MarkMove(true); break; case kEditCut: EditCut(); break; case kEditTest: EditTest(); break;
case kEditJumpBack|k_Repeat:case kEditJumpBack: SkipSeconds(-10); break;case kEditJumpForward|k_Repeat:case kEditJumpForward: SkipSeconds( 10); break; default: { displayFrames = DisplayedFrames; switch (Key) {
--------------------------------------------------------------------------------
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
--------------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.13/47 - Release Date: 12/07/2005
Reinhard Nissl wrote:
Personally, I've added that the key 1/3 skips back/forward 10 seconds. But the two keys are intended to be used differently. That's way my patch didn't make it into VDR yet. --- ../vdr-1.3.25-orig/keys.h 2004-12-27 12:10:59.000000000 +0100 +++ keys.h 2005-01-09 18:24:11.000000000 +0100 @@ -65,6 +65,8 @@ enum eKeys { // "Up" and "Down" must be #define kMarkJumpForward k9 #define kEditCut k2 #define kEditTest k8 +#define kEditJumpBack k1 +#define kEditJumpForward k3
#define RAWKEY(k) (eKeys((k) & ~k_Flags)) #define ISRAWKEY(k) ((k) != kNone && ((k) & k_Flags) == 0) --- ../vdr-1.3.25-orig/menu.c 2005-05-16 15:59:03.000000000 +0200 +++ menu.c 2005-05-29 18:52:42.000000000 +0200 @@ -3723,6 +3742,10 @@ eOSState cReplayControl::ProcessKey(eKey case kMarkMoveForward: MarkMove(true); break; case kEditCut: EditCut(); break; case kEditTest: EditTest(); break;
case kEditJumpBack|k_Repeat:case kEditJumpBack: SkipSeconds(-10); break;case kEditJumpForward|k_Repeat:case kEditJumpForward: SkipSeconds( 10); break; default: { displayFrames = DisplayedFrames; switch (Key) {
I modified the above patch as follows, and 'learnt' some extra buttons on my remote - BUT IT HASN'T WORKED. any ideas?????? +#define kEditJumpBack kUser1 +#define kEditJumpForward kUser2
-
Carsten Koch -
Joerg Riechardt -
Laurence Abbott -
mike lewis -
Reinhard Nissl -
Rudy Sgorlon -
Simon Baxter