• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

'Sidecar' plug-in for the HDR/HD Fox T2

Sorry,:confused: when I clicked on the link from my android phone it sent me to somewhere completely different. Must be browser cache problems.
 
So this seems to work on BBC4 HD recordings that have the zero-byte NTS file (providing you regenerate both NTS and HMT files). However, it's a manual process, and it would be good if it could be automated, as nearly every recording I make on BBC4 HD sufers from this problem.

Would it be possible to integrate this into Webif in the same way as Auto-Decrypt? Perhaps have another option to mark a folder as "Auto-decrypt and new sidecar" so that it's done automatically on a per-folder basis. It would be good to be able to watch Top of the Pops without faffing around each time.... :-)
 
What happens if you only generate an nts file ?
I know af123 was considering integrating sidecar into the badnts package. I haven't used this package myself so not sure if it is automated or not.
 
Last edited:
I thought zero-byte NTS files were an artefact of old firmware versions?

Zero byte HMT files seem to cause more of a problem to the operation of the machine anyway. It ought to be possible to scan for these periodically and delete/reconstruct them automatically.
 
I thought zero-byte NTS files were an artefact of old firmware versions?

Zero byte HMT files seem to cause more of a problem to the operation of the machine anyway. It ought to be possible to scan for these periodically and delete/reconstruct them automatically.
Under what circumstances are zero byte HMT files generated ?
 
I thought zero-byte NTS files were an artefact of old firmware versions?
There was a problem which got fixed, but there is another problem which seems to affect those services immediately after a retune until a dummy recording is made (or something, I'm not chasing up the details and stand to be corrected). What the exact consequence is (zero NTS or whatever) I am not sure.
 
Just checked and badnts is automated. Needs to have Auto-decrypt enabled on the folder for it to work.

I suspect that in the case of a zero length nts being generated, the hmt is flagged as failed "Recording (less than 30 secs) may not be stored", with no "duration" value being set either. If that is the case then a replacement hmt would be required as well as an nts. The channel name and number options for sidecar could be extracted from the old hmt before deleting it.
 
Last edited:
There was a problem which got fixed, but there is another problem which seems to affect those services immediately after a retune until a dummy recording is made (or something, I'm not chasing up the details and stand to be corrected). What the exact consequence is (zero NTS or whatever) I am not sure.

http://myhumax.org/forum/topic/failed-recording-on-new-bbc-four-hd-channel/page/8

I wasn't aware of this which may explain why I've had so many failures on BBC4 HD as I retuned a few weeks back. I'll try as suggested later when BBC4 is on air and see what happens.
 
If you install the badnt
Just checked and badnts is automated. Needs to have Auto-decrypt enabled on the folder for it to work.

I suspect that in the case of a zero length nts being generated, the hmt is flagged as failed "Recording (less than 30 secs) may not be stored", with no "duration" value being set either. If that is the case then a replacement hmt would be required as well as an nts. The channel name and number options for sidecar could be extracted from the old hmt before deleting it.
I'll update badnts to regenerate the sidecar files instead of just deleting them; I had planned to do that once sidecar was released anyway. As raydon says, it does need auto decryption enabled and it triggers automatically following successful decryption. At that point, it is likely that the box will remain on long enough for sidecar to do its work.
 
there is another problem which seems to affect those services immediately after a retune until a dummy recording is made (or something, I'm not chasing up the details and stand to be corrected). What the exact consequence is (zero NTS or whatever) I am not sure.
That was the first recording on BBC3/4 HD after a retune and the recording being marked as decrypted when it wasn't. Proposed fix was to go in auto-unprotect so I guess af123 incorporated it in the rewrite...
 
That was the first recording on BBC3/4 HD after a retune and the recording being marked as decrypted when it wasn't. Proposed fix was to go in auto-unprotect so I guess af123 incorporated it in the rewrite...
Yep.
 
I tried it on an "import" and got this. Turns out that Humax .ts files are 192 byte packets (really .m2ts files, with the 0x47 at offset 4), whereas normal .ts files are 188 bytes (with 0x47 at offset 0).
Converting 188 to 192 with ffmpeg, renaming back to .ts, then feeding it into sidecar makes it work.
It would be nice if it could detect both formats and work seamlessly...
For that you should use AV2HDR-T2. I've got an update in the pipeline. :D
I found a use for sidecar - I exported my recording of Men in Black 3 (C4 HD) to PC and removed the adverts using VideoReDo TVSuite V5, then imported it again, prior to a screening tonight. The package is a fresh installation today.
Code:
HDRFOX1# sidecar -nh "Men in Black 3"
Error: Source video packet size is 188 bytes, not 192.
HDRFOX1#
Unless VRD has done something to it, it seems the broadcasts can be either 188 byte packets or 192 byte packets. I no longer have the original recording file to check.
 
I found a use for sidecar - I exported my recording of Men in Black 3 (C4 HD) to PC and removed the adverts using VideoReDo TVSuite V5, then imported it again, prior to a screening tonight. The package is a fresh installation today.
Code:
HDRFOX1# sidecar -nh "Men in Black 3"
Error: Source video packet size is 188 bytes, not 192.
HDRFOX1#
Unless VRD has done something to it, it seems the broadcasts can be either 188 byte packets or 192 byte packets. I no longer have the original recording file to check.
All recordings made on T2 have 192 byte packet size. Export from Video redo should be set to M2TS to recreate 192 byte packet format.
 
Broadcasts use 192 byte packets. Looks like VRD has stripped off the time-code headers.
 
:rolleyes:

Bugger. Looks like I'll have to re-run VRD on the edited file then, but it won't be worth it for a "one night only" showing. The file plays OK (and generates a .hmi).
 
Back
Top