Re: [bug vdr-1.3.33] invalid LastReplayed() opens first folder

Udo Richter wrote:
> Hi Klaus,
> 
> I've found a minor bug in the new cMenuRecordings.
> 
> If the recordings menu is opened with OpenSubMenus=true and with 
> cReplayControl::LastReplayed() pointing to a non-existing recording, VDR 
> descends into the first recording sub menu, provide that the first 
> recording menu item is a sub-menu, not a recording.
> ...

The attached patch should fix this.
It also avoids an unjustified "Error while accessing recording!" after
deleting a recording from a subfolder.

Klaus

--- menu.c	2005/09/25 13:37:21	1.362
+++ menu.c	2005/10/01 10:12:32
 <at>  <at>  -1513,6 +1513,7  <at>  <at> 
      SetCurrent(First());
   else if (OpenSubMenus && cReplayControl::LastReplayed() && Open(true))
      return;
+  Display();
   SetHelpKeys();
 }

 <at>  <at>  -1556,7 +1557,7  <at>  <at> 
   if (Refresh) {

Re: vdr-1.3.33, .update detection broken if recording dir != /video

Jon Burgess wrote:
> I just found that the .update detection is broken for me with 
> vdr-1.3.33. I performed and strace on vdr and it is not using the 
> correct recording location:
> 
> stat("/video/.update", 0x7fffffc1e0d0)  = -1 ENOENT (No such file or 
> directory)
> 
> I place my recordings in /video0 using "-v /video0". It looks like the 
> problem is the change which adds the assignment of updateFileName into 
> the constructor of cRecordings:
> 
>   cRecordings Recordings;
> 
>   cRecordings::cRecordings(bool Deleted)
>   :cThread("video directory scanner")
>   {
>     updateFileName = strdup(AddDirectory(VideoDirectory, ".update"));
> 
> It looks like the Recordings object is instantiated before the 
> VideoDirectory has been parsed from the commandline, hence 
> updateFileName always points to the default VIDEODIR.

The attached patch should fix this.

Klaus

--- recording.h	2005/09/25 14:30:13	1.44
+++ recording.h	2005/10/01 10:24:41

Re: only the first 9 lines from commands.conf can be linked from keymacros.conf

Joerg Riechardt wrote:
> I have in keymacros.conf
> Red        Recordings
> #Green     Schedule
> Green      Commands 5
> Yellow     Commands 3
> #Blue      Timers
> Blue       Commands 4
> User1      Commands 6
> User2      Commands 7
> User3      Commands 8
> User4      Commands 9
> #User5      Commands 10
> #User6      Commands 11
> #User7      Commands 12
> I would like to use the last 3 lines as well, but then vdr doesn't 
> start. Obviously only keys 1-9 are accepted, but not 10-12.
> Is there a solution?

There are only 10 numeric keys, numbered 0...9.

You could do

User5 Commands Down Down Down Down Down Down Down Down Down Ok

Klaus

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org

Re: [PATCH] dvb-t, avoid retune on coderateL change

On Sonntag, 11. September 2005 12:44, Stefan Lucke wrote:
> Hi,
> 
> retuning on coderateL change, comes here in Berlin quite often. The attached
> diff fixes that. It could be that this is an error on provider side, but usual
> set top boxes don't show this behavior.

Anyone how tested this ?
If noone needs this, I guess there is none who is recording or viewing ARD
via DVB-T here in Berlin area, or thats only related to my cinergyT2.

> 
> With my diff and debugging enabled I get the following messages in syslog:
> Sep 11 11:16:24 jarada vdr[6566]: channel 14 (MDR FERNSEHEN) event 11:00 'Das Haus in Montevideo' status 4
> Sep 11 11:16:24 jarada vdr[6566]: channel 18 (arte) event 11:15 'Karambolage' status 4
> Sep 11 11:16:41 jarada vdr[6566]:  old check would switch channel
> Sep 11 11:16:41 jarada vdr[6566]:  new code would ignore this change
> Sep 11 11:16:41 jarada vdr[6566]:  old check would switch channel
> 
> instead of these when using old code:
> Sep 11 11:10:22 jarada vdr[6478]:  old check would switch channel
> Sep 11 11:10:22 jarada vdr[6478]:  new code would ignore this change
> Sep 11 11:10:22 jarada vdr[6478]: changing transponder data of channel 1 from
T:522000000:0:1:0:2:2:2:1 to T:522000000:0:1:0:2:1:2:1
> 
> Sep 11 11:10:25 jarada vdr[6543]: [softdevice-audio]: xrun
> Sep 11 11:10:38 jarada vdr[6476]:  old check would switch channel
> Sep 11 11:10:38 jarada vdr[6476]:  new code would ignore this change
> Sep 11 11:10:38 jarada vdr[6476]: changing transponder data of channel 1 from
T:522000000:0:1:0:2:1:2:1 to T:522000000:0:1:0:2:2:2:1

Re: [bug vdr-1.3.33] "Error while accessing recording" after deleting

Udo Richter wrote:
> Hi Klaus,
> 
> I've tracked down a nasty "Error while accessing recording!" / "Fehler 
> beim Ansprechen der Aufzeichnung!" OSD message, occurring sometimes when 
> deleting recordings in sub folders. This only occurs if the deleted file 
> was the first one that was added to that sub folder - and maybe some 
> other conditions.
> 
> Thats what imho happens:
> -The file gets removed from OSD menu, Recordings list and disk.
> -cMenuRecordings::ProcessKey(kNone) triggers a Set() update of the 
> current menu.
> -After that, ProcessKey(kNone) of the main recordings menu triggers a 
> second Set() for the main recordings menu.
> -The second Set() call tries to remember the currently selected menu 
> entry (the currently open sub-menu) by calling GetRecording() for it.
> -GetRecording tries to find the matching recording by comparing file names.
> -Folders use the file name of one of their recordings as dummy, and, by 
> bad luck, this one is the one that was just deleted.
> -GetRecordings fails and throws the error.
> 
> 
> Something similar should happen if the currently selected menu item gets 
> externally deleted, but thats less likely.

I've come across this, too.
The patch I have posted here a little while ago under

   Re: [vdr] [bug vdr-1.3.33] invalid LastReplayed() opens first folder

Re: only the first 9 lines from commands.conf can be linked from keymacros.conf

Klaus Schmidinger wrote:

> Joerg Riechardt wrote:
> 
>> I have in keymacros.conf
>> Red        Recordings
>> #Green     Schedule
>> Green      Commands 5
>> Yellow     Commands 3
>> #Blue      Timers
>> Blue       Commands 4
>> User1      Commands 6
>> User2      Commands 7
>> User3      Commands 8
>> User4      Commands 9
>> #User5      Commands 10
>> #User6      Commands 11
>> #User7      Commands 12
>> I would like to use the last 3 lines as well, but then vdr doesn't 
>> start. Obviously only keys 1-9 are accepted, but not 10-12.
>> Is there a solution?
> 
> 
> There are only 10 numeric keys, numbered 0...9.
> 
> You could do
> 
> User5 Commands Down Down Down Down Down Down Down Down Down Ok
> 
> Klaus

Re: skincurses doesn't work

Thomas Glomann wrote:
> Klaus, could you please add a little hint to your INSTALL or README or MANUAL 
> file that one has to add the line "OSDSkin = curses" to the setup.conf file 
> in order to make the skincurses plugin work?
> I didn't find that information inside your Dokumentation files. (vdr-1.3.33)

I've added a note to the README file of skincurses.

Klaus

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: Vdr and Parental Lock

Luca Olivetti wrote:
> ...
> Klaus, may I suggest channel categories (e.g. movies, news, films,
> general entertainmnent, music, children, adult, etc.) instead
> of/additionally to favorites? (with the provision that a channel may be
> in more than one category).

The user will be able to create an arbitrary folder structure, and
any channel may be in any number of different folders.

But this is post-1.4 stuff...

Klaus

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: Cleanup Thread (like .update)

hgm.bg wrote:
> Hi Klaus,
> 
> Is there a possibility to implement the same way .update works a way to
> start the cleanup thread which is deleting the deleted recordings ? I'm
> usually low an diskspace and when try to free space for new recordings it
> takes mostly more than 5 minutes of an idle VDR to delete the recordings on
> the system. Sometimes 5 Minutes is too long :). Is this harcoded anywhere in
> the code ? Than it would be enough for me to shorten this amount of time.

recording.c:

#define REMOVECHECKDELTA 3600 // seconds between checks for removing deleted files

Klaus

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: Different between '#define MAXOSDAREAS 16' and '#define MAXNUMWINDOWS 7'

Udo Richter wrote:
> Webmaster wrote:
> 
>> why is "#define MAXNUMWINDOWS 7" defined in dvbosd.c
>> and "#define MAXOSDAREAS 16" in osd.h ?
>> Its not the same and only 7 areas possible to create ??
>> Its a limit to the OSD/card ?
> 
> 
> MAXNUMWINDOWS=7 is the maximum number of areas that FF DVB cards 
> support. VDR however uses a more abstract interface that supports up to 
> MAXOSDAREAS=16 different areas, provide that the OSD device can handle 
> them. To know the real number of supported areas, you have to do several 
> calls to CanHendleAreas.
> 
> Unfortunately, VDR does not enforce MAXOSDAREAS itself, so you may be 
> able to call SetAreas(...,100) on a very flexible OSD device, which will 
> probably lead to a solid crash due to non-handled cOsd internal buffer 
> overruns.
> 
> Cheers,
> 
> Udo

That's what the CanHandleAreas() function is for.
cOsd::SetAreas() calls the CanHandleAreas() of the derived
cOsd class, and in there cDvbOsd checks wheter (NumAreas > MAXNUMWINDOWS).

Klaus