OP
No, that's the puzzling thing. There's no stored state or configuration.
Can you point a web browser at
http://humax/browse/sizes.jim?dir=/media/My+Video
and see what that says?
[FlatView] Provide flattened view of recordings
- Thread starter af123
- Start date
Can you point a web browser at
http://humax/browse/sizes.jim?dir=/media/My+Video
and see what that says?
OP
Flatview uses the modification time of the .ts file to determine age. Usually the .ts doesn't change once it's recorded (and any stripping/ad-detection is done) but your 11 must have a newer modification time. Perhaps flatview should use the recording date from the .hmt file instead.
MymsMan
Ad detector
Good thing Flatten doesn't call hmt +setfilename
(unlike TS renamegroup)
OP
Yes (I had to check) but the DLNA indexer can reset the filename in the .hmt so this may still not work : (Good thing Flatten doesn't call hmt +setfilename
MontysEvilTwin
Well-Known Member
I've attached two files, the first was without FlatView installed, then I reinstalled and repeated. It looks better, but the FV folder only has three recordings in it at the moment, one of which is River, which is one of the culprits.
I have now changed the 'ignore files older than' setting from 2 days back to 7 days (how it was before) and I've attached another file (output from the link you supplied) now the 22.25 cronjob has run. There are more discrepancies in Web-If again now the contents of the FV folder have increased.
Ezra Pound
Well-Known Member
Not sure what time stamps get changed when a *.ts file is watched, but watching '11' earlier this evening has changed the *.hmt file date stamp, i.e.
Code:
humax# ls -al Hitchhiker\'s11_20140517_1800.*
-rw-r--r-- 1 root root 2072 Oct 14 19:00 Hitchhiker's11_20140517_1800.hmt
-rw-r--r-- 1 root root 266592 May 17 2014 Hitchhiker's11_20140517_1800.nts
-rw-r--r-- 1 root root 200044544 May 17 2014 Hitchhiker's11_20140517_1800.ts
humax#MymsMan
Ad detector
Perhaps the friend should turn off Content Share before the indexer makes things worse.
MontysEvilTwin
Well-Known Member
If you play a TS file the only timestamp which will change will be the date accessed. If you crop a TS file or copy one from another partition or drive this will update both the date created and modified fields or the modified field which will make it appear like a new recording. The HMT file is written to and saved whenever you press stop, but if the HMT file were to be used for the time and date of the recording it would be the values within the file, as defined in the HMT format document in the wiki, that would be used not the external timestamp.
Ezra Pound
Well-Known Member
Agreed, but I couldn't find any dates less than 90 days old within the *.hmt file :-
Code:
humax# hmt Hitchhiker\'s11_20140517_1800.hmt
Format:SD
Title:Hitchhiker's11
ITitle:Hitchhiker's Guide to the Galaxy
Channel:708 (BBC Radio 4 Ex)
Folder:/mnt/hd2/My Video/Hitchhiker's Guide to the Galaxy/
Filename:Hitchhiker's11_20140517_1800
Genre:Entertainment (48)
EPG:Fit the Eleventh: On Brontitall, Arthur meets an archaeologist, gets captured and learns all about the Shoe Event Horizon. From January 1980. Episode 5 of 6.
Raw file is encrypted on disk.
Recording Status: Valid (OK)
Flags: SD,Unlimited Copies,ODEncrypted,
Copy count:0
Scheduled start:1400346000 (Sat May 17 18:00:00 2014)
Scheduled duration:1800
Recording start:1400346042 (Sat May 17 18:00:42 2014)
Recording end:1400347840 (Sat May 17 18:30:40 2014)
Duration:1798
Stored duration:1789
Play resumes at:37 seconds in.
Timezone offset:3600
Service ID (SID):5824
Event ID:49203
Transport Stream ID (TSID):4165
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):1700
Video PID:1702
Audio PID:1702
Bookmarks:0 =
humax#
cdmackay
Active Member
I am probably to blame for this one. I was concerned that mutliple threads from the humaxtv process may be accessing a linked hmt file at the same time. Perhaps I was being overly cautious.
OP
Yes, first-processed wins.
OP
Do you know if the box is linked to RS? If this doesn't work then I may be able to extract the original folder structure from an RS database backup.Thank you very much indeed, I've asked him to give it a try.
And it really isn't me
Ezra Pound
Well-Known Member
Would it help to rename the OPT+ 'Toggle No-flatten' icon to read 'Toggle No-flatten / No-flatview' or something similar
Black Hole
May contain traces of nut
I would prefer it had a separate flag, and to be able to over-ride "[" folders. The reasons for preventing a folder being flattened do not coincide with the reasons to prevent flatview indexing the recordings (and that's all it really is - a method of indexing).
Ezra Pound
Well-Known Member
If Flatview proves to be reliable, I can't see any reason not to make it a built-in feature of the Web-If, In my view it also makes Flatten redundant
Black Hole
May contain traces of nut
Only in your opinion does flatview make flatten redundant - I have the opposite opinion (and I guess you're not a flatten fan). They do different things, and there is no reason they can't coexist.
Neither should flatview be forced on anyone by integrating it into the WebIF. As with most of the packages, it's a matter of personal choice and unless another package is dependent on it there is no reason to install it by default.
Neither should flatview be forced on anyone by integrating it into the WebIF. As with most of the packages, it's a matter of personal choice and unless another package is dependent on it there is no reason to install it by default.
Ezra Pound
Well-Known Member
The point is that flatview is non destructive, if you don't use the [Flatview] folder then everything else is as it was before it was installed, it provides the best of both worlds, unlike flatten which destroys the folder hierarchy permanently (with the possible exception of af123's recent fix) . Would you like to explain the advantages of flatten over flatview in YOUR opinion?