Nicesplice Magic Folders Problems

[Starbase]

I've been using Nicesplice Magic Folders with the remote control to edit the start and end of programs for some time, with great success.

Recently I'm having issues when editing certain recorded channels, unwatchable program edits are created. The edited programs appear to have been created correctly, but when I try to view them, they are immediately rejected, the box reverting back to the folder view for selection?

The channels that I have noticed doing this so far are are:-
Channel 5+1, 5 USA and Movies4Men, any ideas?

 

[Black Hole]

Wouldn't surprise me if there is some kind of difference in the broadcast data which is incompatible with nicesplice. We have had a variety of problems with new services, notably the corrupt sidecar files when recording BBC THREE HD and BBC FOUR HD (and others) when they were introduced (until Humax updated the firmware). Even now there are problems recording these services immediately after a retune (weird). Another problem is with services which have a piggy-back data channel wanting a smart TV or set-top box to fetch extra content from the Internet - these cause the Humax to crash if there are problems with the Internet connection (it's OK if there is no connection at all).

Something you could do to try to overcome the problem is to run the recording through Shrink before nicesplice. Shrink is a function on the WebIF media browser OPT+ button, and it strips out the 'dross' in the .TS file. I'm not sure whether the product is compatible with nicesplice - try it with a known good recording first. You could also try the WebIF Crop operation instead of nicesplice.

Let us know how you get on, it might indicate how nicesplice needs to be modified.

 

[prpr]

You could also try the WebIF Crop operation instead of nicesplice.

I think you'll find Webif crop is nicesplice.

 

[DelftBlue]

Recently I'm having issues when editing certain recorded channels, unwatchable program edits are created. The edited programs appear to have been created correctly, but when I try to view them, they are immediately rejected, the box reverting back to the folder view for selection?
The channels that I have noticed doing this so far are are:- Channel 5+1, 5 USA and Movies4Men, any ideas?

I have noticed the same problem with recordings from 5* and Quest.

Cropping produces a .ts file with the expected size, (e.g. original file size = 1,985,173 KB, and output cropped file size = 1,486,562 KB)

The sidecar files of .nts and .hmt appear as usual, but the .ts file won't play on the Humax.

However the .ts file will play fine elsewhere (e.g. on PC via Samba and VLC) which would indicate the problem lies with the .hmt and/or .nts files.

It makes no difference whether the cropping is done via TV screen Magic Folders or via Web-if, or whether the file is shrunk, unshrunk, enrypted or decrypted.

Recordings from other channels still crop without problem, so what is the common factor with the problematic channels? Any ideas?

Four of them share the same Mux:

5* is Number: 30 on Mux: COM4/SDN
5 USA is Number: 31 on Mux: COM4/SDN
QUEST is Number: 37 on Mux: COM4/SDN
Channel 5+1 is Number: 44 on Mux: COM4/SDN

but one is on a different Mux:

Movies4Men is Number: 48 on Mux: COM5/ARQ A

 

[Black Hole]

Have you tried deleting (or renaming) the sidecar files to see if the naked .ts plays on the Humax?

 

[DelftBlue]

Have you tried deleting (or renaming) the sidecar files to see if the naked .ts plays on the Humax?

Just have If you 'remove' the sidecar files by renaming them, then the .ts file on its own will play on the Humax. Sidecar files are def part of the problem.

To explore the mux angle further, I did test recordings of the first two channels on COM4/SDN, number 10: ITV3 and number 16: QVC - then tried to crop them. Neither of the cropped files would play normally. So its possible that all channels on that mux have the same problem.

I noticed I had ITV4+1 at 26, which is out of date, as 26 is now ITVbe, so I re-tuned, however that made no difference to the cropping problem.

This is a recent change, as recordings from 5* previously used to crop and play fine. Weird.

 

[Drutt]

I should have time to have a look over the next few days. Been a while though, so might take me a bit of time to re-familiarise myself with the code! Hopefully if the problem is with the sidecars, rather than the .ts it shouldn't be too nasty. Sounds like something wrong with the metadata - if the frame offset information is out it normally still plays ok, just seeking and so on that breaks.

Could be worth manually copying the sidecars from the orriginal and seeing what happens?

 

[DelftBlue]

Could be worth manually copying the sidecars from the original and seeing what happens?

Hi Drutt - Many thanks for having a look at this.

As you suggested, I did a test last night - copying the original sidecar files onto the cropped .ts file - and it will then play - albeit with incorrect tracking and data and all the pre-cropping video and bookmarks reappeared.

It does seem like the problem is with the sidecar files of cropped recordings from that mux. Somehow they get mangled in the cropping process, and the file will not then play. However without the sidecar files the cropped .ts file will play fine, and the video appears cropped as required.

 

[Drutt]

I've made a bit of progress on this - Nicesplice removes any excess data at the start of the stream if it is before the first frame pointed to by the nts (which contains all the frame indexes). Prelimary investigations are showing this is causing the problem for some reason. Will hopefully get to the bottom of it and get a new version out soon.
Been slightly distracted by the excitement of finally aquiring a HDR to play with (was quick off the mark with a £25 bargin on ebay!)

 

[Starbase]

Hi DelftBlue, thanks for following up on my original post about issues with Nicesplice Magic Folders and providing more information, also many thanks to Drutt for investigating it, I hope you get to the bottom of the problem soon

 

[escat]

I can confirm and add to DelftBlue's report. For me, the problem arises if I crop ANY of the recordings I have made from channels on the COM4 Mux (specifically the ITV3 and Drama channels) from the afternoon of September 24th right up to today. I believe that date coincides with either the latest OTA, or the installation of the latest CF. (I can do some more investigation if this would help). I have a small number of recordings from the COM5 Mux, but none of them demonstrate the problem.

I can confirm that the naked .ts files will play on the Humax, and that the problem does not lie with the .hmt files. For the record, the only differences between the hmt files for the original and the cropped recordings (both successful and failing) appear to be:
1) The move of the start address for the folder path from offset 0180 to offset 017F. NB: this may reflect that NiceSplice is still working to the old format. Since this field isn't actually used, it doesn't really matter, but it would be tidier and less confusing to correct it.
2) The change in the recording end time, to correspond to the shorter recording, at offset 0284.
3) The setting of the bookmark counter to 0, at offset 0298
4) The appearance of a character X'45' at offset 073D - a field whose purpose has never been clear - at least to me!

I can confirm that one can substitute the .nts file from the original recording in place of that from the failed crop, and consequently play the recording, though with less than satisfactory trick-play feature. I also note that one can even replace the failing .nts file with one from an equal length crop of a completely different programme, with just as good results.

I hope Drutt can find a solution to this problem. I'd be happy to perform more tests or analysis if that would help.

 

[af123]

0x73d is the language tag for the guidance text shown on the i-plate. It's usually the fixed string 'eng' for English. We abuse this slightly by using a capital E in the first place to indicate that the recording has been shrunk (that is, EPG data packets have been removed). If your original recording had no guidance text then you'll just see a capital E appear.

 

[escat]

0x73d is the language tag for the guidance text shown on the i-plate. It's usually the fixed string 'eng' for English. We abuse this slightly by using a capital E in the first place to indicate that the recording has been shrunk (that is, EPG data packets have been removed). If your original recording had no guidance text then you'll just see a capital E appear.

Thanks for this. Yes, my notes say that I should expect to see the language field there, specifically 'eng'. But, in practice, it never actually seems to be there. So feel free to abuse away! Thanks again (and for everything else you do for us.)

 

[DelftBlue]

I believe that date coincides with either the latest OTA, or the installation of the latest CF.

Thank you for further input.

I don't think further investigation is needed on the CF angle, as one of my boxes hasn't been updated. The problem seems universal, so I doubt the problem is connected with installation of the latest CF.

Many thanks to Drutt for looking into this. (Still having fun with the excellent ebay bargain?

 

[Drutt]

Don't really understand why, but these problem recordings just seem to need more of the stream before the first frame marked in the nts to be kept. Nicesplice threw most of this away, but I've just uploaded a new version that keeps a bit of a "lead-in". Seems to do the trick on the test recordings I've made. Let me know how you get on...

 

[escat]

Don't really understand why, but these problem recordings just seem to need more of the stream before the first frame marked in the nts to be kept. Nicesplice threw most of this away, but I've just uploaded a new version that keeps a bit of a "lead-in". Seems to do the trick on the test recordings I've made. Let me know how you get on...

Many thanks for this. I've tried the new version on three recordings from two different channels. They all failed before, but all work now. So thanks again.

 

[Starbase]

Hi, I've only had time to try one file from CH5+1, but it worked okay, so it looks like it is fixed, many thanks

 

[DelftBlue]

I've just uploaded a new version that keeps a bit of a "lead-in". Seems to do the trick on the test recordings I've made. Let me know how you get on...

Hooray! Finally had time to test the new version of Nicesplice this afternoon and ... Yes, it works on the problem recordings here too.

Many, many thanks for fixing this, Drutt.

Sending a virtual plate of jaffa cakes (or other comestible of your choice) flying through the ether to you as a thank you.