Corrupt recordings + nicesplice issue

[jack616]

Just an FYI

Since the last retune (just before xmas) I've had a range of odd problems - not least of which
was the need to retune several times just to get decent recordings (1 main box plus the one it loops through to)

Things seem to have mostly settled down now however I have noticed some issues I thought worth mentioning:
The enc flag seems unable to be cleared by any process on (very occasional) recordings - both boxes
including trying to delete sidecars and remake them.

Nicesplice went wrong a few itterations ago with the"grab current timeshift option" in that it never now
clears the enc flag on HD recordings at all (It did do this initially) - it seems impossible to manually do this on these.
Whether this is related to the issue that brought me here I dont know ... anyway that issue is:

Since that last retune I've been seeing these fixed enc flags randomly - and also nicesplice failing to to cut
some recordings.

Using the webif (Looking very nice these days by the way) - nicesplice is reporting "end of file marker found in packets"
(or similar message) - maybe nicesplice could just be made to ignore these?

The cut point can often be moved past this and it will cut fine - but sometimes it can't cut at all.
I've had this on 5 recordings in total.

I suspect something may also have changed in the way programs are transmitted/TS-encoded but not sure.

Also for some reason the new channel 81 (old movies) seems to randomly cut recordings off eg after 37 minutes it stops
recording or 64minutes or whatever. Just this channel. Very odd and I cant seem to cure that.

Just thought I'd mention all this in case it rings a bell with others.

 

[Black Hole]

I suspect something may also have changed in the way programs are transmitted/TS-encoded but not sure.

http://hummy.tv/forum/threads/what-does-enc-mean-on-my-sd-recording.6438/

Also for some reason the new channel 81 (old movies) seems to randomly cut recordings off eg after 37 minutes it stops recording or 64minutes or whatever. Just this channel. Very odd and I cant seem to cure that.

This will be them playing free and loose with the AR flags, presuming you are using AR. Either switch to padding, or install the multimode package and declare Old Movies to be converted to padding (requires a reboot to occur between setting up a recording and the recording occurring).

If you also use the arbookmarks package, you will see (in a padded recording) where the broadcaster actually sent the AR markers and how well/badly they were placed.

Refs:
Things Every... (click) section 3.

 

[jack616]

Thanks for the links BH.
I always use padding (2 mins each end) although it's often got it wrong and started or stopped late.
It just seems the most likely method to be reliable - but ...

I'll keep an eye on that thread if I see a need or can add anything.

 

[Black Hole]

I always use padding (2 mins each end) although it's often got it wrong and started or stopped late.
It just seems the most likely method to be reliable - but ...

In that case you need to check that the broadcaster is actually transmitting the programmes to start and finish at the times stated in the EPG. Auto-padding recordings do not benefit from updating parameters from the EPG immediately prior to the recording - the recording times will be dictated by the parameters in the EPG the last time the box was awake.

 

[MymsMan]

Using the webif (Looking very nice these days by the way) - nicesplice is reporting "end of file marker found in packets"
(or similar message) - maybe nicesplice could just be made to ignore these?

The cut point can often be moved past this and it will cut fine - but sometimes it can't cut at all.

It is quite normal for this message to be generated because some times the .nts indicates there are more frames in the recording than actually in the .ts file but this only occurs at the very end of a recording.

I did discover a bug in nicesplice where this message could be triggered by a very short frame earlier in the recording which I reported to Drutt (nicesplice author) in September - I am not sure if the fix ever made it into the package.

 

[jack616]

sorry - just remembered this thread.

BH this "ignoring" of padding has been going on with every humax I've had to use (over 15 in total - now down to my own 2)
The timestamp on the files shows the late start or short ending (start+runtime to work out) and I've watched it happen
live more than once so I know its the boxes not broadcast variations. Increasing or removing the padding doesn't cure it.

One thing I noticed was one box looped through the other can be up to 3 minutes different to the other (2 minutes plus the hidden seconds to be more precise)
and this can just float back and forth - but that doesnt explain the very late starts (anything from round about 8 up to 54 minutes late)

Like the zero length nicesplice issue - I just put up with it now.
If it wasn't for your custom firmware I'd have chucked these boxes long ago.

 

[Black Hole]

BH this "ignoring" of padding has been going on with every humax I've had to use (over 15 in total - now down to my own 2)

I don't understand how this can be the case for you and not for everyone else. It's fair to assume your units were a random sample, so we have to look for another common factor: your installation or the user. Are you specifically recording only on services which are known to be problematic - ie the minor digital backwater channels?

 

[jack616]

BH
I fully understand you don't understand - neither do I ...
I've looked for common factors and found none.
Random channels BBC1-HD and BBC3-HD has done it but mostly I'm recording movie channels on the off chance theres something
worth watching.

I do get rows of white dashes across the first half of the first scanline on some channels (70 - 81 and others) but I've never
seen anyone else mention that either - that's a permanent feature anyone would see. I expect thats a broadcast issue though.

If I was really worried anymore I'd look into it - maybe find out how the padding is calculated - software or if it's just RTC based etc.
Either way I doubt theres much can be done about it. I did try one box before I put the CF on it and it still happened so I know it
isn't CF related.
There is something odd about both my current boxes but again - I've given up looking.


P.S.... To steal a phrase - life .... don't talk to me about life....

 

[Black Hole]

What worries me is that you seem to have had a bad experience which is not representative in general. It should be possible to sort it out. I suppose you have already been advised to perform a careful manual tuning rather than rely on the auto-scan?

Ref: Things Every... (click) section 2.

 

[Ezra Pound]

I do get rows of white dashes across the first half of the first scanline on some channels (70 - 81 and others)

This normal and is down to the broadcaster, this is probably not reported by many users because it can be eliminated by using setting on your TV, try fiddling with the TV's display settings, by switching between 16:9, Just Scan, Over Scan etc.

 

[jack616]

Repeated odd issues with multiple boxes .. so what I'd be questioning is how representative the lack of other reports actually is.
Short of taking stuff back to the retailer most people tend not to do anything about faulty white goods.

I did try manual tuning a while back but found no real benefit - we don't seem to have issues that indicate multiple
transmitters or anything like that.
At the time I was having problems with the boxes doing repeated cold resets every time channel 85 (I think it was) was tuned in.
Humax were very good about it and swapped the boxes 5 times in 30 days without question. I suspect they must
have known about some sort of issue. Just the same I got so concerned they'd think I was taking the mickey that I went so far as to
make a movie of one box doing it and including a full 360 degree camera view to prove nothing else was plugged in!

I'd like to think it was all coincidence but I can honestly say I find the reliabilty of these boxes to be the lowest of any
piece of electronics of any sort I've ever owned.
That being said - the earlier freeview boxes were just hilarious in their poor behaviour I suppose.

 

[Black Hole]

Repeated odd issues with multiple boxes .. so what I'd be questioning is how representative the lack of other reports actually is.

You think the forum regulars might be brushing things under the carpet???

I'd like to think it was all coincidence but I can honestly say I find the reliabilty of these boxes to be the lowest of any piece of electronics of any sort I've ever owned.

I have four HDR-FOXes (not to mention HD-FOXes) in constant daily use, not missed a beat in 5½ years (ignoring terrible reliability of AR for the first year, unrepeatable by other users under similar circumstances, which cleared up after a self-induced factory reset, and ignoring the occasional system freeze that is inevitable if left on for extended periods). The only time I sent one back was because a factory refurb arrived dented. I have another in store as a spare.

I am aware of a number of other multi-owner forum members with similar experience of reliability. We would certainly be moaning about it on the forum if the same had been happening as you report, which is why I think there's something wrong that ought to be addressable (not by Humax - their tech support is about as useful as a chocolate fire guard).

 

[MontysEvilTwin]

I did discover a bug in nicesplice where this message could be triggered by a very short frame earlier in the recording which I reported to Drutt (nicesplice author) in September - I am not sure if the fix ever made it into the package.

Recently I have increasingly found that cropping high def. recordings fails due to EOF packets. I have had this before when there have been signal problems but in these cases, if I play the original files, there are no problems with signal glitches around the unwanted crop points. Drutt - please could you look at this when you have time.
While on nicesplice, there has always been an issue that when a section is removed, the sound drops out for a number of seconds after the join point. Interestingly, playback on another device, such as a Raspberry Pi with Kodi or an Android tablet with BS Player, does not suffer from this. I have noticed that some joins are 'cleaner' than others: a join can be quite blocky. When the joins are cleaner, the sound dropout seems to be shorter in duration. If you have a blocky join, if you move the crop point, either before or after the join, by a second or so this may give a cleaner join which also reduces the length of the sound dropout.

 

[Theothersimon]

Recently I have increasingly found that cropping high def. recordings fails due to EOF packets. I have had this before when there have been signal problems but in these cases, if I play the original files, there are no problems with signal glitches around the unwanted crop points. Drutt - please could you look at this when you have time.

Can I second this request? The cropping of HD recordings is getting increasingly likely to fail. I'm up to about 50% of recordings now.

 

[MymsMan]

Can I second this request? The cropping of HD recordings is getting increasingly likely to fail. I'm up to about 50% of recordings now.

As a temporary fix you could try the nsplice program shipped with the detectads package to see whether it fixes the problem (/mod/webif/plugin/detectads/nsplice)
This would help confirm whether or not it is the same problem that I found last year.

Whilst I tried not to break anything when adapting nicesplice for use in detectads I can't guarantee not to have introduced other bugs!

 

[MontysEvilTwin]

As a temporary fix you could try the nsplice program shipped with the detectads package to see whether it fixes the problem (/mod/webif/plugin/detectads/nsplice)
This would help confirm whether or not it is the same problem that I found last year.

I retrieved an original recording that had had a crop failure (that'll confuse Google indexing) with nicesplice and ran nicesplice from the command line. I then ran nsplice on the original too. The output is below:

One# cd /media/"My Video"
                                             
One# nicesplice -in "a" -out "b" -cutBookMarks                                 
Found bookmark at - 1                                                           
Found bookmark at - 3539                                                       
progLen = 3623s, 2 bookmarks, HD = 1                                           
Read 91564 entries from nts                                                     
cut at 1.0 seconds = frame 20 (3017)                                           
cut at 3539.0 seconds = frame 89052 (3541091)                                   
-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++                     
Read failure/EOF within frame 67467 skipping rest of file                       
                                                                               
Wrote 67440 entries to b. Stripped 666856 packets (125035k) of EPG data         
New Program Length = 2692s                                                     
now shrunk                                                                     
One#                                                                           

One# /mod/webif/plugin/detectads/nsplice -in "a" -out "b" -cutBookMarks         
Found bookmark at - 1                                                           
Found bookmark at - 3539                                                       
progLen = 3623s, 2 bookmarks, HD = 1                                           
cut at 1.0 seconds = frame 20 (3017)                                           
cut at 3539.0 seconds = frame 89052 (3541091)                                   
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
Wrote 89031 entries to b. Stripped 872092 packets (163517k) of EPG data         
New Program Length = 3537s                                                     
One#

This is only one example, but nsplice cropped the recording correctly where nicesplice failed.

 

[prpr]

As a temporary fix you could try the nsplice program shipped with the detectads package to see whether it fixes the problem (/mod/webif/plugin/detectads/nsplice)

Whilst I tried not to break anything when adapting nicesplice for use in detectads I can't guarantee not to have introduced other bugs!

Is this a fork of the original from Drutt's source code then?

 

[Theothersimon]

As a temporary fix you could try the nsplice program shipped with the detectads package to see whether it fixes the problem (/mod/webif/plugin/detectads/nsplice)
This would help confirm whether or not it is the same problem that I found last year.

I tried it on six files that failed under 'nicesplice'. With 'nsplice' five of them cropped correctly. The sixth produced a correct length, but unplayable file (when you choose 'play' it drops you back into the file display).

So nsplice is definitely better.