U4 series to folder, Dir count

[grampus]

My U4 seems to have had a major conniption on the HDD.
Ive had it for a few days, since Wednesday
After going to 17.5 20180313
I added series to folder and dir numcount.
Wed and thursday all seemed as expected. I was able to setup and use series to folder and the numcount was working.

Pardon the question, Are these compatible with the U4?


The problem I found this morning leads me to ask the question
Might all be misleading.

But this morning, original view of my media showed that recordings I did last night had multiple entries of each recording. Similar to a continual reboot.
Probably around 4 minutes for each entry.
Seemed to have lost my view of any individual movies.
Power indications around the house doesn't give any indication of any power loss overnight.

I exited media view, and back in again. I now have lost all the above mentioned recordings. They are not evident, nor in the trash

/hdd/movie entry shows that I have 53 files and 6 directories along the top line of the display.
Its as if they have become "hidden files"
Yet all I can see is the trash directory.
The trash directory shows me that I have a number of files there, 10 or so, these are expected as I deleted them last night.
I haven't seen this sort of thing before.
Hence the question.

Right now, I'm about to go back to default and start working my way up from there.
****
Just checked via the file commander, and all my expected entries are shown.
Once again its as if the files are hidden via the "media" entry.
****************

[grampus]

Reverted to system defaults.
Files are now back in the media view.
I must have twinkle fingered something.

[adoxa]

I've updated dir-count (although I think the only thing new was correct sorting of split recordings, so it shouldn't have caused a problem).

[prl]

...
But this morning, original view of my media showed that recordings I did last night had multiple entries of each recording. Similar to a continual reboot.
Probably around 4 minutes for each entry.
Seemed to have lost my view of any individual movies.
...

IIRC an exception caused while building the display list to paint the media list on the screen can cause entries to disappear. That's more likely to be related to dircount than to Series2Folder, because Series2Folder doesn't deal with the display of the media list, and dircound's intention is to change the way that the media list is displayed. If Series2Folder is run manually, it will ask the media selection list to reload after things have been moved to folders, but otherwise it doesn't access the media selection data.

Series2Folder will also avoid moving things to folders while the movie selection screen (or File Commander screen) is active, for obvious reasons.

[grampus]

The thing that i may offer as a possibility to what happened to me, is that I had 2 abberations.
1: The fact that I had a heap of individual files for a couple of recordings overnight, Chinatown, No Offence, Unforgotten. like as if there had been a reboot or restart not regularly, But a fair sort of selection of each file being anywhere between 2 minutes to maybe 6 minutes

2: The fact of the disappearing files in the media display.

So I wonder what could fire off at these seemingly random intervals, that could cause trigger the multiple recordings.

Just as an aside.
but in my mind it would be nice if the TOD shown in the media display would come from the current time TOD, that the recording started, not the start time as defined by the timer.

In my case the multiple files was an extreme case, but it would help in some instances for the user to be able to pick up which file they wished to view readily.
Just may be an enhancement request?

[adoxa]

but in my mind it would be nice if the TOD shown in the media display would come from the current time TOD, that the recording started, not the start time as defined by the timer.

I was almost going to do this - change the file name to the current time - but I'd already done MovieJoin then and that relies on the file names being the same, plus sorting by time would spread the parts between other recordings. However, I now realise that wouldn't have worked anyway, as the display time comes from the meta and that comes from the begin time of the timer. (I was also almost going to change the meta time when you cut the start padding, but that wouldn't work should you happen to do it twice. Hm, I think I could store both a display time and begin time in the meta.) Anyway, I can change the meta time to the time the recording starts (actually, prepares), but there's no U4 SDK yet, so I can't give you anything to test. For those that could build it, here's the (untested) diff:

Code: Select all

diff --git a/lib/service/servicedvbrecord.cpp b/lib/service/servicedvbrecord.cpp
index 46f71c5db..8ccf6c0c2 100644
--- a/lib/service/servicedvbrecord.cpp
+++ b/lib/service/servicedvbrecord.cpp
@@ -130,7 +130,8 @@ RESULT eDVBServiceRecord::prepare(const char *filename, time_t begTime, time_t e
 				}
 			}
 
-			meta.m_time_create = begTime;
+			time_t now = time(NULL);
+			meta.m_time_create = now > begTime ? now : begTime;
 			meta.m_ref = m_ref;
 			meta.m_data_ok = 1;
 			meta.m_service_data = service_data;

[prl]

I'm not convinced yet that changing the start times would be a good idea, even though it would fix some other problems. If, for some reason, a recording gets broken up, I think it would be good for all its parts to have the same timestamp in the filename, as it is now, because they are pats of the same recording.

[prl]

... there's no U4 SDK yet, so I can't give you anything to test. ...

There is (I've used it), but it was distributed from the U4 beta area, so you may not have access to it.