Re: [vdr] Tuner switch when timer starts recording
On 18.11.2009 08:40, Falk Spitzberg wrote: Hello, With VDR 1.7.9 i often notice that VDR switches the live TV to a different receiver card, when a timer starts recording, although the second card is available. This causes a short interrupt in live TV. My system has two DVB cards, an old FF and a Tevii S470, and an eHD. Sample situation 1: the only activity is live TV on ZDF. Now a timer starts recording from RTL 2, which interrupts the live program for a short moment. Sample situation 2: the only activity is live TV on RTL. Now a timer starts recording from RTL 2. Nothing happens, because VDR correctly shares the transponder with live TV. I would understand when VDR switches live TV from the DVB-S2 card to the DVB-S card when it needs to tune a different transponder for a DVB-S2 recording, but since it can do DVB-S recordings from any card, there is no reason to switch live TV for such recordings. When recording, VDR tries to preserve devices that provide multiple delivery systems: imp = 2; imp |= GetClippedNumProvidedSystems(2, device[i]) - 1; // avoid cards which support multiple delivery systems See device.c, cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [path] vdr-1.6 better spu on ff card
Hi, I'm not sure if I got it right: This patch reduces the amount of memory that is needed for a osd by splitting the osd into several areas and adjusting the bbp for each area. Regards, JW Am Samstag, den 21.11.2009, 21:57 +0100 schrieb matthieu castet: Hi, this patch try to handle case where the osd is limited (for example on ff card). For that it try to split area, count the really needed bpp (all transparent index can be merged together and will with my previous patch in osd.c). Also it fix a bug in the current version : removing all the transparent baground area is ok only if it is recomputed at each draw. Otherwise a highlight request can happen outside the computed area. With this patch I can navigate in dvd menu that produce oeOutOfMemory before. Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Odd filesystem errors
On 07.11.2009 02:07, HighlyCaffeinated wrote: I've got an unusual situation with my VDR installation that has me completely stumped. My /video0 directory is located on a 1TB ext2 filesystem. When I perform an 'ls-al' I get an incomplete list of the directories located there. If I open that filesystem on a Windows box via Samba, I see that two recent directories have been created that the 'ls' does not show me. The directories are named COO66K~7 mailto:vdr@linuxtv.org(a CSI recording) and N3OZM1~R (an NCIS recording) in Windows. I can drill down into either directory and find the expected filesystem structure and two recordings that we had thought had failed. They are only visible through Windows/Samba. I can copy the contents of the directory to a Windows box and then copy them back to VDR (with a new folder name) and they play normally. As Debian refuses to acknowledge their existence, I cannot rename or delete the directories and I cannot copy data from the subdirectories. I have tried masking the tilde in the filenames, and that didn't change anything as I suspect the filenames are instead REALLY long. I am running vdr 1.7.7 with ATSC tuners and the ATSCepg plugin, and the system regularly creates successful recordings. Anyone with a pointer on how to deal with this and what may be causing such an odd set of circumstances? e2fsck didn't find anything it considered to be bothersome. Can you check the syslog file to see what names VDR used to create the recording directories? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Odd filesystem errors
Klaus Schmidinger schrieb: On 07.11.2009 02:07, HighlyCaffeinated wrote: I've got an unusual situation with my VDR installation that has me completely stumped. My /video0 directory is located on a 1TB ext2 filesystem. When I perform an 'ls-al' I get an incomplete list of the directories located there. If I open that filesystem on a Windows box via Samba, I see that two recent directories have been created that the 'ls' does not show me. The directories are named COO66K~7 mailto:vdr@linuxtv.org(a CSI recording) and N3OZM1~R (an NCIS recording) in Windows. I can drill down into either directory and find the expected filesystem structure and two recordings that we had thought had failed. They are only visible through Windows/Samba. I can copy the contents of the directory to a Windows box and then copy them back to VDR (with a new folder name) and they play normally. As Debian refuses to acknowledge their existence, I cannot rename or delete the directories and I cannot copy data from the subdirectories. I have tried masking the tilde in the filenames, and that didn't change anything as I suspect the filenames are instead REALLY long. I am running vdr 1.7.7 with ATSC tuners and the ATSCepg plugin, and the system regularly creates successful recordings. Anyone with a pointer on how to deal with this and what may be causing such an odd set of circumstances? e2fsck didn't find anything it considered to be bothersome. That is normal situation on a samba share that has (windows) illegal characters in it's name. eg: CSI: Next Session is illegal because of the : and will be translated to something like you have seen on the windows box. Peter Can you check the syslog file to see what names VDR used to create the recording directories? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.8 shows wrong recording length
On 06.09.2009 13:38, Martin Dauskardt wrote: I have a TS recording of more than two hours which seems to have no errors (Project X demux log looks fine). When I start playing it with vdr, the replay osd shows a recording lenghth of only 9 minutes. The same values is displayed in the recording menu (yes I know, this is not a vdr feature but comes from a patch) Is it worth to investigate it? I still have this recording on my disc. Please check whether this problem still persists in version 1.7.10. You can regenerate the index with version 1.7.10. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.9 fails to record one channel
On 25.10.2009 21:54, Marek Hajduk wrote: I have same problem with vdr 1.7.9 e.g. channel: Nova Sport HD;skylink:12109:hC910M2O20S1:S23.5E:27500:4005=27:4165=cze,4245=eng:0:D70,D 03:5045:3:3221:0 I thing Klaus know about it. I'm afraid I won't be able to test that myself, because I don't have an LNB pointing to S23.5E, and furthermore this channel is encrypted. Please check whether this problem still persists in version 1.7.10. Klaus -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Jouni Karvo Sent: Sunday, October 25, 2009 3:54 PM To: VDR Mailing List Subject: [vdr] VDR 1.7.9 fails to record one channel hi, I have the following problem: When live viewing with 1.7.9 and vdr-xine 0.9.3, this channel (in cable) is shown properly: TV7;HTV:386:M128:C:6900:800+802=2:801=fin:0:0:61500:42249:16:0 If I try to record anything, vdr restarts constantly, and the recording is of zero length. The output of vdr (or xine) says: DiscontinuityDetected: triggering soft start With 1.7.7 and the same vdr-xine version, recording works, but vdr is not able to jump forward or backward in the recording. 1.7.9 is also able to show the recordings made with 1.7.7 (but not able to jump forward or backwards.) Any debugging hints? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Editing recordings and no instant video update when moving markers
On 16.09.2009 15:53, Ian Bates wrote: Hello, When editing recordings I am struggling to fine tune marker placement as adjustments made with '4' and '6' keys while moving the marker as indicated by the time line do not update the video display with the corresponding position in the recording. Current setup: SW: VDR-1.7.9 (with freesat patch), NVIDIA driver 185-something, xineliboutput and xine as outptut plugins, ffmpeg-svn / xine-lib-1.2-hg from about two weeks ago, v4l-dvb-hg from about two weeks ago, slackware64-current OS HW: M2NPV-VM with onboard Nvidia 6150, Athlon something 64 bit dual core (at least 2.1GHz), a couple of SATA disks. - This problem only occurs with TS recordings, PES recordings made with vdr-1.7.0 with this setup work as expected. - With the xineliboutput plugin the display does not update at all when moving the marker. - With xine plugin the display updates but with seemingly random time intervals, from almost realtime as expected to delays of 1-5 seconds to sometimes not at all, depending on the recording and the position of the marker. I have a tedious workaround: set marker, play - If adjustment needed then - select marker, adjust with '4' or '6', play, repeat until no further adjustment needed. Does anyone have the same problem? Does anyone NOT have this problem? What can I do to fix this? Please check if this problem still exists in VDR version 1.7.10. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] ttxtsubs patch for vdr-1.7.10
Hi, just thought I'd post an unofficial ttxtsubs patch for vdr-1.7.10 in case someone wants to use it. /Magnus H vdr-1.7.10-ttxtsubs.patch Description: application/mbox ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] GOTOX patch and vdr-1.7.10
Last version of this patch from is applicable and functioning also with vdr-1.7.10. See http://www.linuxtv.org/pipermail/vdr/2009-April/020248.html. Regards, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.9 fails to record one channel
Now, with vdr 1.7.10, I can record channel Nova Sport HD. It seems problem was solved. BR Marky -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: Sunday, November 22, 2009 3:59 PM To: vdr@linuxtv.org Subject: Re: [vdr] VDR 1.7.9 fails to record one channel On 25.10.2009 21:54, Marek Hajduk wrote: I have same problem with vdr 1.7.9 e.g. channel: Nova Sport HD;skylink:12109:hC910M2O20S1:S23.5E:27500:4005=27:4165=cze,4245=eng:0:D70,D 03:5045:3:3221:0 I thing Klaus know about it. I'm afraid I won't be able to test that myself, because I don't have an LNB pointing to S23.5E, and furthermore this channel is encrypted. Please check whether this problem still persists in version 1.7.10. Klaus -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Jouni Karvo Sent: Sunday, October 25, 2009 3:54 PM To: VDR Mailing List Subject: [vdr] VDR 1.7.9 fails to record one channel hi, I have the following problem: When live viewing with 1.7.9 and vdr-xine 0.9.3, this channel (in cable) is shown properly: TV7;HTV:386:M128:C:6900:800+802=2:801=fin:0:0:61500:42249:16:0 If I try to record anything, vdr restarts constantly, and the recording is of zero length. The output of vdr (or xine) says: DiscontinuityDetected: triggering soft start With 1.7.7 and the same vdr-xine version, recording works, but vdr is not able to jump forward or backward in the recording. 1.7.9 is also able to show the recordings made with 1.7.7 (but not able to jump forward or backwards.) Any debugging hints? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.7.10: missing reset of file size
I'm afraid I forgot to reset the file size when regenerating the
index file. This should fix this in case the recording is split
over several files:
--- recording.c 2009/11/22 11:20:53 2.18
+++ recording.c 2009/11/22 19:38:04
@@ -1412,8 +1412,11 @@
// Read data:
else if (ReplayFile) {
int Result = Buffer.Read(ReplayFile, BufferChunks);
- if (Result == 0) // EOF
+ if (Result == 0) { // EOF
ReplayFile = FileName.NextFile();
+ FileSize = 0;
+ FrameOffset = -1;
+ }
}
// Recording has been processed:
else {
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] Don't hardcode lirc socket path in the sky plugin
Hello,
The attached patch avoids hardcoded lirc socket path in the sky plugin, making
it use the value from Make.config by default. The patch is against 1.6.0-2
but appears to apply cleanly to 1.7.10 as well.
diff -up vdr-1.6.0/PLUGINS/src/sky/Makefile~ vdr-1.6.0/PLUGINS/src/sky/Makefile
--- vdr-1.6.0/PLUGINS/src/sky/Makefile~ 2008-01-13 15:00:16.0 +0200
+++ vdr-1.6.0/PLUGINS/src/sky/Makefile 2009-11-22 22:37:27.0 +0200
@@ -41,7 +41,8 @@ PACKAGE = vdr-$(ARCHIVE)
INCLUDES += -I$(VDRDIR)/include
-DEFINES += -D_GNU_SOURCE -DPLUGIN_NAME_I18N='$(PLUGIN)'
+LIRC_DEVICE ?= /dev/lircd
+DEFINES += -D_GNU_SOURCE -DPLUGIN_NAME_I18N='$(PLUGIN)' -DLIRC_DEVICE=\$(LIRC_DEVICE)\
### The object files (add further files here):
diff -up vdr-1.6.0/PLUGINS/src/sky/sky.c~ vdr-1.6.0/PLUGINS/src/sky/sky.c
--- vdr-1.6.0/PLUGINS/src/sky/sky.c~ 2008-03-22 12:19:32.0 +0200
+++ vdr-1.6.0/PLUGINS/src/sky/sky.c 2009-11-22 22:33:03.0 +0200
@@ -88,7 +88,7 @@ cDigiboxDevice::cDigiboxDevice(void)
apid = vpid = 0;
struct sockaddr_un addr;
addr.sun_family = AF_UNIX;
- strn0cpy(addr.sun_path, /dev/lircd, sizeof(addr.sun_path));//XXX parameter???
+ strn0cpy(addr.sun_path, LIRC_DEVICE, sizeof(addr.sun_path));//XXX parameter???
fd_lirc = socket(AF_UNIX, SOCK_STREAM, 0);
if (fd_lirc = 0) {
if (connect(fd_lirc, (struct sockaddr *)addr, sizeof(addr)) 0) {
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.10
Greetings Klaus. Thanks for the new version! It seems the ffwd/rew crash on certain HDTV recordings is now fixed so thats great news! However, the problem still exists where if I start replaying a recording while it's still recording, the length increases very quickly to ridiculous numbers. The replay stops at the point in the recording which I started playback. If I delete the index file and have VDR generate a new one, I still get the crazy recording length and the audio/video is out of sync. Maybe VDR should not actually start playback until after the new index file is generated? Although that won't fix the problem of starting playback before the recording has finished. Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF/RW problems with xine
On Fri, 2009-10-09 at 21:07 +0200, Carsten Koch wrote: On Fri, 2009-10-09 at 11:37 -0700, Timothy D. Lenz wrote: With some recordings FF/RW doesn't work correctly. The video/audio stops and when you hit play again, it has moved to the new a new location. Some recordings work, some don't. I saw that, too. It has to do with the channel. I record WAS IST WAS TV for my kids from Nickelodeon. On these recordings, FF/FR never works, which makes it kind of hard to cut these recordings. I checked again with 1.7.10. (tried cutting a WAS IST WAS TV recording today) The bug is still there. Carsten. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
