Re: [vdr] Watching old recordings with DVB subtitles with 1.6.0
On Saturday 12 April 2008, Rolf Ahrenberg wrote: > On Sat, 12 Apr 2008, Ville Skyttä wrote: > > After figuring out how to access the subtitles menu (my remote.conf was > > from 1.4.x series so there was no button binding for it), yes, I do see > > an entry named "57" there. Selecting it gives me the Finnish subtitles I > > was looking for. Thanks for the tip. > > You could also map "57" to "fin" in info.vdr of all those old recordings > and afterwards VDR automatically selects subtitles according to > preferred languages. I tried to do that, but did not succeed so far. The old recordings I tried this with had no "X" lines in info.vdr, but they do have this selectable "57" entry in the subtitles menu. New recordings from the same channel (MTV3 Scifi) have both "X 3 03 fin " and "X 3 03 sve " there, and Finnish subtitles do show up automatically when replaying these. So I tried "X 3 03 fin ", "X 3 57 fin ", and "X 57 03 fin " in the old recordings' info.vdr but that did not seem have any effect. Tried also touching .update and restarting VDR in between, as well as replacing 57 with 39 and 87 (just in case there would have been a dec<->hex conversion somewhere). "SubtitleLanguages = fin 57" hack in setup.conf didn't help either. Did I miss something? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
On Saturday 12 April 2008, Klaus Schmidinger wrote: > On 04/09/08 08:54, Stefan Lucke wrote: > > On Wednesday 05 March 2008, Klaus Schmidinger wrote: > >> On 03/04/08 10:58, Tero Siironen wrote: > >>> Hi, > >>> > >>> I upgraded from VDR 1.4.7 to 1.5.17 and noticed that some of my old > >>> recordings won't play decently with this new version. Here's a syslog > >>> entry and example clip can be found from > >>> http://kotisivu.suomi.net/izero/vdr-darwin/ddmode_example.zip > >>> (9MB) > >>> > >>> Those problematic recordings were done with some 1.3.x series VDR with > >>> ttxtsubs plugin in fall 2004. Plays fine with VDR 1.4.7, but playback > >>> stutters when playing with VDR 1.5.17. My system has DVB-C FF 2.1 and > >>> DVB-C budget cards. Running on Fedora 5. > >> My guess would be that the offending data comes from the ttxtsubs plugin. > >> Maybe you need to patch VDR to become aware of this. > > > > My guess is that this is introduced by vdr-1.5.11 > > > > Original vdr-1.6.0: > > Apr 9 08:29:38 jarada vdr: [7997] replay > > /net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec > > Apr 9 08:29:38 jarada vdr: [7997] playing > > '/net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec/001.vdr' > > Apr 9 08:29:38 jarada vdr: [7997] loading > > /net_data/video/Extra/Enterprise_1/%1-01_Aufbruch_ins_Unbekannte_-_Teil_1/2004-01-31.19:05.99.99.rec//marks.vdr > > Apr 9 08:29:38 jarada vdr: [8019] dvbplayer thread started (pid=7997, > > tid=8019) > > Apr 9 08:29:38 jarada vdr: [8020] non blocking file reader thread started > > (pid=7997, tid=8020) > > Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = EB > > (counter is at 0) > > Apr 9 08:29:38 jarada vdr: [8019] unknown PS1 packet, substream id = 0B > > (counter is at 1) > > Attached pach fixes this problem for me. > > Your patch changed two things: the MIN_PRE_1_3_19_PRIVATESTREAM stuff, which > merely > made detection of pre 1.3.19 Dolby Digital data more reliable, and the > (Data[7] & 0x01) > check in "// Compatibility mode for old subtitles plugin:". I assume that the > latter one > is what's causing your problems. > > Can you please reinstate the MIN_PRE_1_3_19_PRIVATESTREAM stuff and check > whether just > leaving out the (Data[7] & 0x01) check is enough to fix this? I guess you meant the following change only: --- device.c.orig 2008-03-09 11:03:34.0 +0100 +++ device.c2008-04-12 17:30:45.0 +0200 @@ -1265,7 +1265,7 @@ int PayloadOffset = Data[8] + 9; // Compatibility mode for old subtitles plugin: - if ((Data[7] & 0x01) && (Data[PayloadOffset - 3] & 0x81) == 0x01 && Data[PayloadOffset - 2] == 0x81) + if ((Data[PayloadOffset - 3] & 0x81) == 1 && Data[PayloadOffset - 2] == 0x81) PayloadOffset--; uchar SubStreamId = Data[PayloadOffset]; With this change it is still the same issue: no sound at all. Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 62 (counter is at 8) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA (counter is at 9) Apr 13 09:48:11 jarada vdr: [7765] switching to pre 1.3.19 Dolby Digital compatibility mode - substream id = DA Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA (counter is at 0) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 41 (counter is at 0) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B (counter is at 1) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = D6 (counter is at 2) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = C6 (counter is at 2) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 5A (counter is at 3) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B (counter is at 4) Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 6C (counter is at 4) Wondering why the are different substream ids are reported with the same counter value ;-). > > This additional check was suggested by Marco Schlüßler, so maybe he can > comment > on this and maybe find out why this is interfering with the pre 1.3.19 Dolby > Digital > detection? > Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
Hi,
Stefan Lucke schrieb:
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 62
(counter is at 8)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA
(counter is at 9)
Apr 13 09:48:11 jarada vdr: [7765] switching to pre 1.3.19 Dolby Digital
compatibility mode - substream id = DA
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA
(counter is at 0)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 41
(counter is at 0)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B
(counter is at 1)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = D6
(counter is at 2)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = C6
(counter is at 2)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 5A
(counter is at 3)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B
(counter is at 4)
Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 6C
(counter is at 4)
Wondering why the are different substream ids are reported with the same
counter value ;-).
This additional check was suggested by Marco Schlüßler, so maybe he can comment
on this and maybe find out why this is interfering with the pre 1.3.19 Dolby
Digital
detection?
Maybe I should have posted this patch to the list earlier too.
Without the patch, the counter will restart from 0 and prevent
VDR to run in compatibility mode just after VDR was going to
activate compatibility mode.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.18-dvbs2-other/device.c 2008-03-19 22:33:06.0 +0100
+++ device.c 2008-04-06 18:53:53.0 +0200
@@ -1335,6 +1346,7 @@ pre_1_3_19_PrivateStreamDeteced:
if (pre_1_3_19_PrivateStream > MIN_PRE_1_3_19_PRIVATESTREAM) {
dsyslog("switching to pre 1.3.19 Dolby Digital compatibility mode - substream id = %02X", SubStreamId);
ClrAvailableTracks();
+pre_1_3_19_PrivateStream = MIN_PRE_1_3_19_PRIVATESTREAM + 1;
goto pre_1_3_19_PrivateStreamDeteced;
}
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
On 04/13/08 10:54, Reinhard Nissl wrote: > Hi, > > Stefan Lucke schrieb: > >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> 62 (counter is at 8) >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> DA (counter is at 9) >> Apr 13 09:48:11 jarada vdr: [7765] switching to pre 1.3.19 Dolby >> Digital compatibility mode - substream id = DA >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> DA (counter is at 0) >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> 41 (counter is at 0) >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> 0B (counter is at 1) >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> D6 (counter is at 2) >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> C6 (counter is at 2) >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> 5A (counter is at 3) >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> 0B (counter is at 4) >> Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = >> 6C (counter is at 4) >> >> Wondering why the are different substream ids are reported with the >> same counter value ;-). >> >>> This additional check was suggested by Marco Schlüßler, so maybe he >>> can comment >>> on this and maybe find out why this is interfering with the pre >>> 1.3.19 Dolby Digital >>> detection? > > Maybe I should have posted this patch to the list earlier too. Without > the patch, the counter will restart from 0 and prevent VDR to run in > compatibility mode just after VDR was going to activate compatibility mode. You've beat me by just a few seconds - I was just about to post the patch you sent me privately, too ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Watching old recordings with DVB subtitles with 1.6.0
On 04/13/08 09:27, Ville Skyttä wrote: > On Saturday 12 April 2008, Rolf Ahrenberg wrote: >> On Sat, 12 Apr 2008, Ville Skyttä wrote: >>> After figuring out how to access the subtitles menu (my remote.conf was >>> from 1.4.x series so there was no button binding for it), yes, I do see >>> an entry named "57" there. Selecting it gives me the Finnish subtitles I >>> was looking for. Thanks for the tip. >> You could also map "57" to "fin" in info.vdr of all those old recordings >> and afterwards VDR automatically selects subtitles according to >> preferred languages. > > I tried to do that, but did not succeed so far. > > The old recordings I tried this with had no "X" lines in info.vdr, but they > do > have this selectable "57" entry in the subtitles menu. New recordings from > the same channel (MTV3 Scifi) have both "X 3 03 fin " and "X 3 03 sve " > there, and Finnish subtitles do show up automatically when replaying these. > > So I tried "X 3 03 fin ", "X 3 57 fin ", and "X 57 03 fin " in the old > recordings' info.vdr but that did not seem have any effect. Tried also > touching .update and restarting VDR in between, as well as replacing 57 with > 39 and 87 (just in case there would have been a dec<->hex conversion > somewhere). "SubtitleLanguages = fin 57" hack in setup.conf didn't help > either. Did I miss something? The old subtitle patch/plugin used 0x28 as the starting offset for subtitle tracks, while the current implementation uses 0x20. I guess this was because the old remux.c had the line ts2pes[numTracks++] = new cTS2PES(*SPids++, resultBuffer, IPACKS, 0x00, 0x28 + n++); commented as "future..." and the subtitle patch just enabled this one. When I implemented subtitle handling in the core VDR code, I realized that this should actually be 0x20 instead. You can work around this by adding the lines X 3 03 X 3 03 X 3 03 X 3 03 X 3 03 X 3 03 X 3 03 X 3 03 X 3 03 fin suomi to your info.vdr files. This fills up the first 8 slots and puts "suomi" into the 9th slot. Don't forget to "touch /video/.update" after this change. Of course we could also modify cDevice::PlayPesPacket() to subtract 8 from SubStreamIndex in case the "// Compatibility mode for old subtitles plugin" check was positive, but you would still have to add X 3 03 fin suomi to your info.vdr files in order to get automatic subtitle track selection. So I guess the above workaround should do just fine. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
On Sunday 13 April 2008, Reinhard Nissl wrote: > Hi, > > Stefan Lucke schrieb: > > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 62 > > (counter is at 8) > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA > > (counter is at 9) > > Apr 13 09:48:11 jarada vdr: [7765] switching to pre 1.3.19 Dolby Digital > > compatibility mode - substream id = DA > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = DA > > (counter is at 0) > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 41 > > (counter is at 0) > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B > > (counter is at 1) > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = D6 > > (counter is at 2) > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = C6 > > (counter is at 2) > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 5A > > (counter is at 3) > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 0B > > (counter is at 4) > > Apr 13 09:48:11 jarada vdr: [7765] unknown PS1 packet, substream id = 6C > > (counter is at 4) > > > > Wondering why the are different substream ids are reported with the same > > counter value ;-). > > > >> This additional check was suggested by Marco Schlüßler, so maybe he can > >> comment > >> on this and maybe find out why this is interfering with the pre 1.3.19 > >> Dolby Digital > >> detection? > > Maybe I should have posted this patch to the list earlier too. Ack. Maybe I should have tested my old recordings a bit earlier ;-) . > Without the patch, the counter will restart from 0 and prevent Bingo. With patch, vdr-1.6.0 could replay these old recodings with sound, at least normal stereo. Thanks. > VDR to run in compatibility mode just after VDR was going to > activate compatibility mode. > Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading to VDR-1.6.0 and CAM : does not decrypt anymore
On 03/31/08 10:25, Pierre-Yves Paranthoen (PERSO) wrote: > Hi, > > I'm a VDR user for a few years now. I was using vdr-1.4.7 until today and > wanted to upgrade to the 1.6.0 version. > I just compiled and installed the 1.6.0 version over the previous running > one. I noticed that VDR was modifying the channels.conf by tagging encrypted > channels. I also remarked a random detection of tha cam module. It gives > sometimes the correct model of the cam, sometimes not. The result of course > is VDR is not decoding encrypted channels anymore. > ... > PS : my setup : > > vdr-1.6.0 - dvb-s drivers from 2.6.20 kernel with dvb-ttpci-01.fw-2622 under > a Hauppauge WINTV NEXUS S - ASTON CAM with valid subscription card from > CanalSat (France ASTRA 19.2) Please try changing #define MODULE_CHECK_INTERVAL 100 // ms in ci.c to, say, 500. Let me know if this changes anything. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] ERROR: attempt to open OSD while it is already open - using dummy OSD!
On 03/28/08 11:31, Wolfgang Rohdewald wrote:
> On Freitag, 28. März 2008, Klaus Schmidinger wrote:
>> On 03/28/08 08:14, Wolfgang Rohdewald wrote:
>>> On Samstag, 22. März 2008, Klaus Schmidinger wrote:
> But vdr does not ask the plugin to hide before trying
> to show the message, so I am getting the same error
> message in that situation. I see no way to get rid of it.
>
> As a possible solution, can the player control somehow
> tell vdr that it can handle the message display itself?
> Something like
>
> class cControl : public cOsdObject {
> public:
> ...
> virtual bool DisplayMessage(...) { return false };
>
> so if a player is active, its DisplayMessage is called.
> Only when it returns false, vdr then tries to display
> the message.
See cSkinDisplayReplay::SetMessage().
>>> the unpatched vdr-1.5.16 does not contain that. Are you sure you
>>> are using an unpatched vdr? (Sorry, could not resist ;-) )
>>>
>>> I do have
>>> void cSkinClassicDisplayMessage::SetMessage(eMessageType Type, const char
>>> *Text)
>> So I omitted the parameters, big deal ;-)
>
> I actually meant cSkinDisplayReplay against cSkinClassicDisplayReplay. No big
> deal, of course.
>
>>> but this plugin does not use skins at all for its player osd.
>>> Just cOsdProvider::NewOsd(). So I dont see how SetMessage() could
>>> help me.
>> You could set your OSDs "level" to something greater than 0.
>> Then it will be pushed into background when a higher level
>> OSD comes up, and restored after that.
>
> thank you, this works. No more error messages in the log. Patch for osddemo
> attached.
>
> Of course the message display is now visually very different from the normal
> player osd. I still think cControl::DisplayMessage() would be useful. Then
> the cControl could better visually integrate the message.
If you really want to "blend in", why doesn't your player use the skin's
"DisplayReplay"? This one displays messages in the way the skin normally
does.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem when playing radio recordings
On 03/25/08 02:19, Jose Alberto Reguero wrote: > When playing radio recordings there are a lot of lines in the logs: > > Mar 25 02:14:46 jar vdr: [32230] > playing '/video/Música/Jazz/2008-01-12.22.00.50.99.rec/001.vdr' > Mar 25 02:14:48 jar vdr:last message repeated 59 times > Mar 25 02:14:48 jar vdr: [32192] [vdrmon] connect from 127.0.0.1, > port -18951 - accepted > Mar 25 02:14:48 jar vdr: [32230] > playing '/video/Música/Jazz/2008-01-12.22.00.50.99.rec/001.vdr' > Mar 25 02:15:12 jar vdr:last message repeated 497 times > > It is that normal? No. This message should only occur when a file is newly opened for replay. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
Klaus Schmidinger wrote: >> Meanwhile I increased constant >> >> MODULE_CHECK_INTERVAL to 300 ms >> >> and now syslog looks much better. >> > > At any rate, if this really fixes the problem for you (please let us > know whether it actually work in the long run) I guess it shouldn't > be wrong to generally set this timeout to 300ms - or maybe even more? It seems stable with 300ms with my CAM, but for reliability reason I set it to 500ms. Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Quota and VDR
On 03/23/08 10:46, Manfred Schmidt-Voigt wrote: > Manfred Schmidt-Voigt schrieb: >> Hello List, >> >> I have a diskless VDR machine in my livingroom (so its very quit). My >> /video is mounted by nfs from a Servermachine under the roof. On that >> server I have set a groupquota for that /video directory to save some >> place for other applikations on that filesystem (raid 5 - 4x400G). >> >> I have exeeded now the space on that filesystem for that group and in >> the syslog of the VDR I can see related messages. >> >> Example: >> Mar 9 08:52:32 stereo vdr: [4167] switching device 1 to channel 1 >> Mar 9 08:52:32 stereo vdr: [4167] timer 18 (1 0852-1152 '@TITLE >> EPISODE') start >> Mar 9 08:52:32 stereo vdr: [4167] Title: 'Tigerenten Club' Subtitle: >> 'Der Club zum Mitmachen' >> Mar 9 08:52:32 stereo vdr: [4167] record >> /video/@Tigerenten_Club_Der_Club_zum_Mitmachen/2008-03-09.08.52.50.99.rec >> Mar 9 08:52:32 stereo vdr: [4167] creating directory >> /video/@Tigerenten_Club_Der_Club_zum_Mitmachen >> Mar 9 08:52:32 stereo vdr: [4167] ERROR: >> /video/@Tigerenten_Club_Der_Club_zum_Mitmachen: Disk quota exceeded >> >> >> But the VDR Software doesn't recognize that. It does not start to mark >> old recording for removing. In the menu overview it show still some >> hours free space util the end of the complete filesystem. >> >> Now my question: Do I have to configure something special in VDR that >> it recognizes the Quota setting of that directory or have I to use >> userquota for the user of VDR (in my case it is root but if it is the >> only solution I could change it to a regular user, but only if it >> helps for my problem)? >> >> Some revision data: >> VDR 1.4.5 ( yes, I'm waiting for 1.6 ) >> Debian Etch on both VDR and Server >> >> >> Thank you >> Manfred >> >> > > Hi List, > > because nobody answers me I have to answer myself: > > No, VDR is not able to follow Quota. It is looking only for the standard > size parameters of the filesystem... ;-( > > So I had to help myself. The outcome is a patch/hack for my current VDR > Version 1.4.5. But it should be easy to apopt it also to newer versions. > I have glued it together out of several GOOGLE sniplets. Maybe somebody > can look over this patch who has more ability to code this according > real C++ styles. I'm not used to progamm in C++. But for this little > patch it was sufficient. > > To use this you have to install the quota package on your server and > maybe the quota-utils on your client. For your convenience I have > included already the rquota-files into this patch. (I hope its according > to any licenses) > > Have fun > Manfred Sorry, but this is really too much to change for implementing quota handling. Besides, if an application actually needs to do this much to follow system quotas, doesn't this mean that apps that just don't care about quotas can do whatever they want? Shouldn't the presence of quotas mean that *every* application sees only parameters that fit the current quota, without even "knowing" that it has been limited? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR maintenance patch 1.6.0-1
VDR maintenance patch 1.6.0-1 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.diff This is a 'diff' against the official version 1.6.0. Small fixes to the officially released VDR versions will be first made available as "maintenance patches" in the Developer directory, so that they can be reviewed and tested before a new official release is published. So please apply this patch to the original VDR version 1.6.0 and report whether it works (or if it causes any new problems). The changes since version 1.6.0: - Fixed handling the counter in detection of pre 1.3.19 PS data (thanks to Reinhard Nissl). - Improved logging system time changes to avoid problems on slow systems under heavy load (suggested by Helmut Auer). - Fixed initializing the timer's flags in the cTimer copy constructor (thanks to Andreas Mair). - Increased the time between checking the CAM status to 500ms to avoid problems with some CAMs (reported by Arthur Konovalov). Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.0
VDR developer version 1.7.0 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.0.tar.bz2 A 'diff' against the latest stable version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.7.0.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 switches to the "multiproto" driver and no longer works with non-multiproto drivers. Hopefully there will soon be *one* driver source that combines the latest "multiproto" version with Oliver Endriss' "full ts mod" changes ;-). Note that this version just implements basic DVB-S2 handling. There is no support for H.264 etc. yet. This will come in later 1.7.x versions. The changes since version 1.6.0: - Re-implemented handling of DVB-S2, which first appeared in version 1.5.14, but was revoked in version 1.5.15 in favor of making a stable version 1.6.0. VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto. Note that the channels.conf file now supports additional parameters, so you may want to make sure you have a backup of this file in case you need to go back to the previous version of VDR! - Fixed displaying transponder data when it is modified (thanks to Reinhard Nissl). - Fixed handling the counter in detection of pre 1.3.19 PS data (thanks to Reinhard Nissl). - Improved logging system time changes to avoid problems on slow systems under heavy load (suggested by Helmut Auer). - Now setting the thread name, so that it can be seen in 'top -H' (thanks to Rolf Ahrenberg). - Fixed initializing the timer's flags in the cTimer copy constructor (thanks to Andreas Mair). - Fixed setting the OSD level in the 'osddemo' example (thanks to Wolfgang Rohdewald). - Increased the time between checking the CAM status to 500ms to avoid problems with some CAMs (reported by Arthur Konovalov). Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Watching old recordings with DVB subtitles with 1.6.0
On Sunday 13 April 2008, Klaus Schmidinger wrote: > > You can work around this by adding the lines > > X 3 03 > X 3 03 > X 3 03 > X 3 03 > X 3 03 > X 3 03 > X 3 03 > X 3 03 > X 3 03 fin suomi > > to your info.vdr files. This fills up the first 8 slots and puts "suomi" > into the 9th slot. That works for me, thanks! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.7.0 does not compile
Hi List, When compiling vdr-1.7.0 i got this error: g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -march=pentium3 -O2 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -ffast-math -fPIC -c -DUSE_CHANNELSCAN -DUSE_CMDSUBMENU -DUSE_CUTTERLIMIT -DUSE_CUTTERQUEUE -DUSE_CUTTIME -DUSE_DELTIMESHIFTREC -DUSE_DDEPGENTRY -DUSE_DOLBYINREC -DUSE_DVDARCHIVE -DUSE_DVLRECSCRIPTADDON -DUSE_DVLVIDPREFER -DUSE_DVLFRIENDLYFNAMES -DUSE_GRAPHTFT -DUSE_HARDLINKCUTTER -DUSE_IPTV -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_LIRCSETTINGS -DUSE_LIVEBUFFER -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NOEPG -DUSE_OSDMAXITEMS -DUSE_PINPLUGIN -DUSE_PLUGINMISSING -DUSE_ROTOR -DUSE_SETTIME -DUSE_SOURCECAPS -DUSE_SORTRECORDS -DUSE_TIMERCMD -DUSE_TIMERINFO -DUSE_VALIDINPUT -DUSE_VOLCTRL -DUSE_WAREAGLEICON -DUSE_YAEPG -DREMOTE_KBD -DREMOTE_LIRC -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR=\"/video\" -DCONFDIR=\"/etc/vdr\" -DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\" -DVFAT -I/usr/include/freetype2 -I/usr/portage/distfiles/hg-src/v4l-dvb-multiproto/multiproto/linux//include dvbdevice.c dvbdevice.c: In member function 'bool cDvbTuner::SetFrontend()': dvbdevice.c:271: error: 'struct dvbfe_info' has no member named 'delivery' dvbdevice.c:286: error: 'struct dvbfe_info' has no member named 'delivery' dvbdevice.c:307: error: 'struct dvbfe_info' has no member named 'delivery' make: *** [dvbdevice.o] Error 1 The driver I am using ist http://jusst.de/hg/multiproto svn from today, and the included frontend.h really has no delivery member in this structure. -- Helmut Auer, [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput plugin - Audio - Visualization - Goom
Hi JJussi, JJussi wrote: > Hi! > Do somebody else have same problem than me.. Because I have FullHD TV I would > like to have that Goom set as 1920x1080 @ 30 fps but I can only use 960x540 > if I want it to be smooth.. > Even I have Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz it's not > enought... That Goom "eats" one CPU (of those two) and frame rate is > something like 3 fps.. > I had the same problem. It seems like goom is very cpu hungry. I got it smooth with these settings: width=512,height=288,fps=25 which are 16:9 not too cpu hungry (it's a vdr not a rendering server) and not too much 'pixeled'. So long, -- Patrick Cernko | mailto:[EMAIL PROTECTED] | http://www.errror.org "... Aber eins haben beide gemeinsam: Mit 16% Alkohol sorgen sie fuer pure Sambastimmung." (Werbeslogan Black Batita) smime.p7s Description: S/MIME Cryptographic Signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.0 does not compile
Hi > dvbdevice.c > dvbdevice.c: In member function 'bool cDvbTuner::SetFrontend()': > dvbdevice.c:271: error: 'struct dvbfe_info' has no member named 'delivery' > dvbdevice.c:286: error: 'struct dvbfe_info' has no member named 'delivery' > dvbdevice.c:307: error: 'struct dvbfe_info' has no member named 'delivery' > make: *** [dvbdevice.o] Error 1 > > The driver I am using ist http://jusst.de/hg/multiproto svn from today, > and the included frontend.h really has no delivery member in this structure. > > delivery was removed 5 weeks ago: http://jusst.de/hg/multiproto/log/46df93f7bcee/linux/include/linux/dvb/frontend.h -- Helmut Auer, [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.0 does not compile
On 04/13/08 18:21, Helmut Auer wrote: > Hi > > >> dvbdevice.c >> dvbdevice.c: In member function 'bool cDvbTuner::SetFrontend()': >> dvbdevice.c:271: error: 'struct dvbfe_info' has no member named 'delivery' >> dvbdevice.c:286: error: 'struct dvbfe_info' has no member named 'delivery' >> dvbdevice.c:307: error: 'struct dvbfe_info' has no member named 'delivery' >> make: *** [dvbdevice.o] Error 1 >> >> The driver I am using ist http://jusst.de/hg/multiproto svn from today, >> and the included frontend.h really has no delivery member in this structure. >> >> > delivery was removed 5 weeks ago: > http://jusst.de/hg/multiproto/log/46df93f7bcee/linux/include/linux/dvb/frontend.h I used the same driver as in VDR version 1.5.14 (dated 2008-01-28). I tried to make today's driver from http://jusst.de/hg/multiproto, mixed with Oliver's full-ts mod stuff, but that didn't compile. So I just used what had worked with version 1.5.14. Let's hope there will soon be a combined driver source... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.0 does not compile
> Let's hope there will soon be a combined driver source... > I guess the driver team cannot ignore the linux killer application :) -- Helmut Auer, [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Announce] vdr-fritzbox-1.0.0
Dear Fritz!Box- and VDR-Users, a new version of the Fritz!Box Plugin is available at http://joachim-wilke.de/index.htm?alias=vdr-fritz This is the recommended stable version for users of VDR 1.6. - - - The Fritz!Box Plugin connects to your Fritz!Box to inform you about incoming calls. The plugin can automatically mute or pause VDR when a call comes in. Via VDR's main menu you can browse your Fritz!Box phone book, the call lists and initiate calls out of all lists. - - - 2008-04-13: Version 1.0.0 - updated italian translations (provided by Diego [24]) - made "This phonebook is not yet available..." error message non-selectable to avoid a segmentation fault when selecting it (reported by ? [25]) - - - Regards, Joachim. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR maintenance patch 1.6.0-1
Hi, On 13 Apr 2008, at 17:38, Klaus Schmidinger wrote: > - Increased the time between checking the CAM status to 500ms to > avoid problems > with some CAMs (reported by Arthur Konovalov). I can confirm that this fixes the CAM initialization issues also for my hardware. Thanks. Tuomas Jormola ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Scan found no PIDs (NIT and TID)
Hello, When I'm using the scan with option -o vdr I have the problem with some channels into channels.conf. In channels.conf for some of them channels the TID & NID pids are missing for example # Sirius: # cat /channels/S4.8E_channels.conf|grep :0:0:0$ B4U;DEFAULT PROVIDER:12302:h:S0.0W:25546:1260:1220:0:0:11:0:0:0 Universal TV;DEFAULT PROVIDER:12302:h:S0.0W:25546:1360:1320:0:0:12:0:0:0 OU Enterprise;DEFAULT PROVIDER:12302:h:S0.0W:25546:1460:1420:0:0:13:0:0:0 Disc_Romania;DEFAULT PROVIDER:12302:h:S0.0W:25546:1560:1520,1522:0:0:14:0:0:0 . ### Hotbird: # cat /channels/S13.0E_channels.conf|grep :0:0:0$ Servizio 23;(null):11432:v:S0.0W:27500:710:711=ita,712=Oth:0:0:23:0:0:0 Servizio 24 ;(null):11432:v:S0.0W:27500:720:721=ita,722=Oth:0:0:24:0:0:0 Servizio 25;(null):11432:v:S0.0W:27500:730:731=ita,732=Oth:0:0:25:0:0:0 .. Amos: # cat /channels/S4.0W_channels.conf|grep :0:0:0$ K1;SPACECOM:10722:h:S0.0W:27500:257:258:0:0:1:0:0:0 OTV;SPACECOM:10722:h:S0.0W:27500:513:514:0:0:2:0:0:0 1PLUS1;SPACECOM:10722:h:S0.0W:27500:769:770,771:773:0:3:0:0:0 TV KYIV;SPACECOM:10722:h:S0.0W:27500:1025:1026:0:0:4:0:0:0 MEGASPORT;SPACECOM:10722:h:S0.0W:27500:1281:1282:0:0:5:0:0:0 K2;SPACECOM:10722:h:S0.0W:27500:1537:1538:0:0:6:0:0:0 1PLUS1 Intern-l;SPACECOM:10722:h:S0.0W:27500:1793:1794:0:0:7:0:0:0 1PLUS1 CINEMA;SPACECOM:10722:h:S0.0W:27500:2049:2050,2051:0:0:8:0:0:0 .. the full list this channels with missing pids you can find here http://upload.sat-universum.de/down/channels/no-tid-nid-channels.conf the log of scan -vvv http://upload.sat-universum.de/down/channels/scan.log My system: Debian ETCH Techno Trend Premium (Full Featured) S2300 V 2.3 "modified" Latest version of Scan from http://linuxtv.org/hg/dvb-apps/ a list of log is created where the two missing PIDs Scan has started with the following options: $ scan -o vdr -p -a 0 -f 0 -d 0 -t 3 -5 -vvv S4.0W.ini > S4.0W_channels.conf ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.0 does not compile
Hi,
Helmut Auer schrieb:
dvbdevice.c
dvbdevice.c: In member function 'bool cDvbTuner::SetFrontend()':
dvbdevice.c:271: error: 'struct dvbfe_info' has no member named 'delivery'
dvbdevice.c:286: error: 'struct dvbfe_info' has no member named 'delivery'
dvbdevice.c:307: error: 'struct dvbfe_info' has no member named 'delivery'
make: *** [dvbdevice.o] Error 1
The driver I am using ist http://jusst.de/hg/multiproto svn from today,
and the included frontend.h really has no delivery member in this structure.
delivery was removed 5 weeks ago:
http://jusst.de/hg/multiproto/log/46df93f7bcee/linux/include/linux/dvb/frontend.h
The attached patch should make it build.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.7.0-orig/dvbdevice.c ./dvbdevice.c
--- ../vdr-1.7.0-orig/dvbdevice.c 2008-04-13 16:15:35.0 +0200
+++ ./dvbdevice.c 2008-04-13 21:16:45.0 +0200
@@ -266,10 +266,6 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBS_TUNE_TIMEOUT;
lockTimeout = DVBS_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, &feinfo)); //switch system
}
else if (frontendType & DVBFE_DELSYS_DVBC) {
Frontend.delivery = DVBFE_DELSYS_DVBC;
@@ -281,10 +277,6 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBC_TUNE_TIMEOUT;
lockTimeout = DVBC_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, &feinfo)); //switch system
}
else if (frontendType & DVBFE_DELSYS_DVBT) {
Frontend.delivery = DVBFE_DELSYS_DVBT;
@@ -302,15 +294,12 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBT_TUNE_TIMEOUT;
lockTimeout = DVBT_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, &feinfo)); //switch system
}
else {
esyslog("ERROR: attempt to set channel with unknown DVB frontend type");
return false;
}
+ CHECK(ioctl(fd_frontend, DVBFE_SET_DELSYS, &Frontend.delivery)); //switch system
if (ioctl(fd_frontend, DVBFE_SET_PARAMS, &Frontend) < 0) {
esyslog("ERROR: frontend %d: %m", cardIndex);
return false;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Scan found no PIDs (NIT and TID)
Hi, Bikalexander schrieb: > When I'm using the scan with option -o vdr I have the problem with > some channels into channels.conf. > In channels.conf for some of them channels the TID & NID pids are missing This shouldn't matter much. I've modified channel 1 in my channels.conf and set NID and TID to 0. When VDR comes across this channel e. g. by an EPG scan or when switching to that channel, VDR will add NID and TID as necessary, as you can see from the following log line: > Apr 13 21:25:13 video vdr: [30455] changing id of channel 1 from 0-0-28106-0 > to 1-1101-28106-0 BTW: VDR must be allowed to modify channels.conf. You can do that in VDR's DVB setup menu. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.0
Hi,
Klaus Schmidinger schrieb:
This version switches to the "multiproto" driver and no longer works
with non-multiproto drivers. Hopefully there will soon be *one* driver
source that combines the latest "multiproto" version with Oliver Endriss'
"full ts mod" changes ;-).
Thanks to Manu Abraham, the merged repository (for ease of use)
is online now:
http://jusst.de/hg/multiproto_plus
It combines the following repositories:
http://jusst.de/hg/multiproto
http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-full-ts-mod
Note that this version just implements basic DVB-S2 handling. There is
no support for H.264 etc. yet. This will come in later 1.7.x versions.
To use the above "up to date" multiproto repositories, you'll
have to apply the attached patch to VDR-1.7.0. Alternatively, you
may want to apply my H.264 patch (see separate email), which
contains the changes for current multiproto too.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.7.0-orig/dvbdevice.c ./dvbdevice.c
--- ../vdr-1.7.0-orig/dvbdevice.c 2008-04-13 16:15:35.0 +0200
+++ ./dvbdevice.c 2008-04-13 21:16:45.0 +0200
@@ -266,10 +266,6 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBS_TUNE_TIMEOUT;
lockTimeout = DVBS_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, &feinfo)); //switch system
}
else if (frontendType & DVBFE_DELSYS_DVBC) {
Frontend.delivery = DVBFE_DELSYS_DVBC;
@@ -281,10 +277,6 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBC_TUNE_TIMEOUT;
lockTimeout = DVBC_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, &feinfo)); //switch system
}
else if (frontendType & DVBFE_DELSYS_DVBT) {
Frontend.delivery = DVBFE_DELSYS_DVBT;
@@ -302,15 +294,12 @@ bool cDvbTuner::SetFrontend(void)
tuneTimeout = DVBT_TUNE_TIMEOUT;
lockTimeout = DVBT_LOCK_TIMEOUT;
-
- dvbfe_info feinfo;
- feinfo.delivery = Frontend.delivery;
- CHECK(ioctl(fd_frontend, DVBFE_GET_INFO, &feinfo)); //switch system
}
else {
esyslog("ERROR: attempt to set channel with unknown DVB frontend type");
return false;
}
+ CHECK(ioctl(fd_frontend, DVBFE_SET_DELSYS, &Frontend.delivery)); //switch system
if (ioctl(fd_frontend, DVBFE_SET_PARAMS, &Frontend) < 0) {
esyslog("ERROR: frontend %d: %m", cardIndex);
return false;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] DVB API Wrapper for VDR 1.7.0
Hi list, There's a new version of the DVB API wrapper patch that adds fallback compatibility to the current stable DVB API without multiproto support. The new version also fixes a bug with the default DVBFE_MOD_AUTO modulation on DVB-S. Also, the patch for VDR-1.5/1.6 that allows to read a channels.conf from 1.7 is now available on that page. Support for DVBFE_SET_DELSYS will follow in next version. Get it: http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] H.264 support for VDR-1.7.0
Hi, attached you'll find an updated patch for VDR-1.7.0. The patch includes now the formerly released addon patches and fixes. Have a look at this page for more instructions on this concern: http://www.vdr-wiki.de/wiki/index.php/OpenSUSE_VDR_DVB-S2_-_xine Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] vdr-1.7.0-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff.bz2 Description: BZip2 compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB API Wrapper for VDR 1.7.0
On 04/13/08 23:06, Udo Richter wrote: > Hi list, > > > There's a new version of the DVB API wrapper patch that adds fallback > compatibility to the current stable DVB API without multiproto support. > > The new version also fixes a bug with the default DVBFE_MOD_AUTO > modulation on DVB-S. Is this fix also relevant for the original VDR 1.7.0? BTW: just curious, but what exactly is the reason for this "API wrapper"? Shouldn't we rather encourage people to switch to the multiproto driver? After all, I did release a stable version 1.6 for those who don't want to (or can't) switch to the multiproto driver. Now we're at a new *developer* version, which should *focus* on making the switch to multiproto. Just my thoughts, no offense intended, and of course it's your decision to maintain such a patch ;-) Klaus > Also, the patch for VDR-1.5/1.6 that allows to read a channels.conf from > 1.7 is now available on that page. > > Support for DVBFE_SET_DELSYS will follow in next version. > > Get it: > http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper > http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Quota and VDR (1.6.0)
Klaus Schmidinger schrieb: On 03/23/08 10:46, Manfred Schmidt-Voigt wrote: Manfred Schmidt-Voigt schrieb: Hello List, I have a diskless VDR machine in my livingroom (so its very quit). My /video is mounted by nfs from a Servermachine under the roof. On that server I have set a groupquota for that /video directory to save some place for other applikations on that filesystem (raid 5 - 4x400G). I have exeeded now the space on that filesystem for that group and in the syslog of the VDR I can see related messages. Example: Mar 9 08:52:32 stereo vdr: [4167] switching device 1 to channel 1 Mar 9 08:52:32 stereo vdr: [4167] timer 18 (1 0852-1152 '@TITLE EPISODE') start Mar 9 08:52:32 stereo vdr: [4167] Title: 'Tigerenten Club' Subtitle: 'Der Club zum Mitmachen' Mar 9 08:52:32 stereo vdr: [4167] record /video/@Tigerenten_Club_Der_Club_zum_Mitmachen/2008-03-09.08.52.50.99.rec Mar 9 08:52:32 stereo vdr: [4167] creating directory /video/@Tigerenten_Club_Der_Club_zum_Mitmachen Mar 9 08:52:32 stereo vdr: [4167] ERROR: /video/@Tigerenten_Club_Der_Club_zum_Mitmachen: Disk quota exceeded But the VDR Software doesn't recognize that. It does not start to mark old recording for removing. In the menu overview it show still some hours free space util the end of the complete filesystem. Now my question: Do I have to configure something special in VDR that it recognizes the Quota setting of that directory or have I to use userquota for the user of VDR (in my case it is root but if it is the only solution I could change it to a regular user, but only if it helps for my problem)? Some revision data: VDR 1.4.5 ( yes, I'm waiting for 1.6 ) Debian Etch on both VDR and Server Thank you Manfred Hi List, because nobody answers me I have to answer myself: No, VDR is not able to follow Quota. It is looking only for the standard size parameters of the filesystem... ;-( So I had to help myself. The outcome is a patch/hack for my current VDR Version 1.4.5. But it should be easy to apopt it also to newer versions. I have glued it together out of several GOOGLE sniplets. Maybe somebody can look over this patch who has more ability to code this according real C++ styles. I'm not used to progamm in C++. But for this little patch it was sufficient. To use this you have to install the quota package on your server and maybe the quota-utils on your client. For your convenience I have included already the rquota-files into this patch. (I hope its according to any licenses) Have fun Manfred Sorry, but this is really too much to change for implementing quota handling. Besides, if an application actually needs to do this much to follow system quotas, doesn't this mean that apps that just don't care about quotas can do whatever they want? Shouldn't the presence of quotas mean that *every* application sees only parameters that fit the current quota, without even "knowing" that it has been limited? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Applications, which do not care about quota, can not really do what they want, they only can not write to the filesystem if the quotalimit is reached. Thats what quota is made for. But if you would like to react on such a limit in a more intelligent way you have to ask for that limit and not only for the simple filesystem limit. statfs(..) only delivers the 'physical' limits of the filesystem. So vdr could not make new recordings when the limit is reached because it checks for the filesystemlimit. This value shows vdr to have enough space. So it never starts to delete old recordings. I have changed the patch a little bit because there was a logical fault in it. But now it's for vdr-1.6.0. I have not tested the xfs part because currently I use only ext3 or nfs. So this should be tested maybe by somebody else or if you would like to implement such a logic into vdr leave it out or comment it out or do it your own way. The problem here is that by each kind of check of the different filesystems you receive different numberunits of something what is called a block. It seems so that all the people, which implements the quotalogic for the different filesystems, had a different thought what a block should look like... Manfred -- --- Manfred Schmidt-Voigt --- -www.mannitec.de - --- mailto:[EMAIL PROTECTED]--- diff -Naur vdr-1.6.0_orig/Makefile vdr-1.6.0/Makefile --- vdr-1.6.0_orig/Makefile 2008-02-29 22:43:03.0 +0100 +++ vdr-1.6.0/Makefile 2008-04-13 23:52:12.0 +0200 @@ -41,7 +41,7 @@ lirc.o menu.o menuitems.o nit.o osdbase.o osd.o pat.o player.o plugin.o rcu.o\ receiver.o recorder.o recording.o remote.o remux.o ringbuffer.o sdt.o sections.o shutdown.o\ skinclassic.o skins.o skinsttng.o so
