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(…
[View More]"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.
Jon
[View Less]
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.
Steps to reproduce:
-Make sure the first entry in recordings is a folder, eg. record
something to AAA~BBB~CCC
-Play some recording DDD~EEE and stop it
-Externally delete/move …
[View More]the DDD~EEE recording (deleting inside VDR
doesn't trigger this)
-touch .update
-Enter recordings menu with direct remote key
Actual result:
Recording sub menu AAA~BBB is opened, CCC is selected.
Expected result:
Recording main menu opened, AAA selected.
Cool enhanced result:
Open the DDD sub menu if it still exists.
Background:
I think, the idea was that Set() selects the proper item, or keeps
Current()<0 otherwise, so the Open() in
cMenuRecordings::cMenuRecordings() is never called. However, the
Display() in Set() automatically selects First() as fallback. The 'if
(Current() < 0)' test in the constructor will never be triggered because
of that.
Cheers,
Udo
[View Less]