• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Some recordings don't save progress

R

rivergo1d

New Member
This seems to crop up a fair bit, more on ITV and channel 4 than on BBC, and so possibly related to the cropping which occurs after advert detection.

I can watch halfway through the program, but the progress bar gets stuck quite early on. If I exit and resume, it picks up from a much earlier point, and only remmebers my position after a fast forward to a later section - not after playing to that same later section.

I have managed to play around with the pre-crop recording, the cropped recording, and the cropped redcording with sidecar files recreated.

The cropped recording will show the problem, but the original version is fine, and the one with new sidecars is fine.

The nts files differ, and as an indicator, the hmt files also show different durations on identical ts files. For the hmt file, the difference between cropped and cropped-plus-new-sidecar is:
-Recording end:1602030368 (Wed Oct 7 01:26:08 2020)
+Recording end:1602030481 (Wed Oct 7 01:28:01 2020)

-Duration:3076
+Duration:3189

-Stored duration:3076
+Stored duration:3189

(-Play resumes at:118 seconds in.) <- stuck
(+Play resumes at:169 seconds in.) <- got past it

Any ideas on what is causing this? I guess I can detect it programmatically by rattling round the filesystem each night for any updated recently added recordings, create new sidecar files and seeing where the duration differs.
 
Just cropping a recording creates trick-play problems because the metadata (in the .hmt and .nts) is then wrong. The .hmt needs updating, and the .nts needs recreating (the .nts contains a large number of pointers to aid skipping etc).

You will also hit problems if you play a recording which is being chase-decrypted, while it is still recording.
 
Cropping with nicesplice does recreate the nts and hmt files

The humax only updates the resume point if you terminate recording nornally with the Stop button which is a PITA because you cant resume properly following a power cut or system crash.

I haven't noticed problems with the progress bar except when chase playing a detectads cropped programme
 
It's detectads cropped, but not chase playing - some of these programmes are very old. My cut/paste of the hmt diffs happens to be a more recent file, because I still had the original in my deleted items folder.

I realise I've put this thread on the wrong Fox board too, it should have been under the customised firmware!
 
If I try to run sidecar within an ssh session, by
cd RECORDING_DIRECTORY
sidecar -nh FILENAME

it spends a while processing but I get a segmentation fault at the end. Is there something else I should be doing when running sidecar?

Or, can I manually regenerate nts and hmt using discrete commands?
 
I had this before running sidecar:

free
total used free shared buffers cached
Mem: 125016 113528 11488 0 4620 65680
-/+ buffers/cache: 43228 81788
Swap: 131064 116 130948
 
rivergo1d said:
Is there something else I should be doing when running sidecar?
Click to expand...
Can you see whether it's the -n or the -h option which is causing the problem? Either way it makes no difference, because Raydon isn't apparently around to fix it, and his code never has bugs anyway.
 
Are there any easy ways of persuading nicesplice to run on a file which no longer has any bookmarks? I'd just like to try running it through that route again to see what happens.
 
I imagine all you have to do is invoke it on the command line. nicesplice itself only does the cropping (it's called "nice" because it looks for a suitable edit point in the stream instead of hacking the stream resulting in video breakup) - if you mean rebuilding the sidecars, that's a separate operation from nicesplice.
 
One thing to note about the Sidecar package is that it was not designed to create sidecar files for Nicesplice-cropped recordings. It will work correctly if the recording has just been 'topped and tailed' but the duration will be incorrect if if sections of the recording have been cropped out. This is because Nicesplice does not reset the timestamps of the joined sections, so as playback proceeds across a joined section, the timestamps jump by the duration of the removed section. On the HDR-FOX this transition manifests as the sound dropping out for a few seconds.
If you remux the Nicesplice-cropped recordings with ffmpeg, Sidecar will then work correctly when recreating hmt and nts files.
 
There has been discussion about using ffmpeg instead of nicesplice to improve the quality of cropping but this hasn't been implemented yet.

In my limited experience nicesplice has been able to rebuild sidecars for cropped files

But why are you rebuilding the sidecars, the files produced by detectads/nicesplice should play without further manipulation

The recording end time is deliberately reduced to reflect the new duration of the recording.
For some reason the humax always uses end-start for showing duration and ignores the Stored duration field in he hmt
 
MymsMan said:
But why are you rebuilding the sidecars, the files produced by detectads/nicesplice should play without further manipulation
Click to expand...
rivergo1d said:
I can watch halfway through the program, but the progress bar gets stuck quite early on. If I exit and resume, it picks up from a much earlier point, and only remmebers my position after a fast forward to a later section - not after playing to that same later section.
Click to expand...
 
You must log in or register to reply here.
Back
Top