• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
  • The forum software that supports hummy.tv has been upgraded to XenForo 2.0!

    This is a major upgrade which changes the look and feel of the forum somewhat but brings a host of improvements too. Please bear with us as we continue to tweak things and report any issues or suggestions in Site/Forum Issues.

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

prpr

Well-Known Member
How difficult, if at all possible, would it be to tweak this so it can process .ts files from an old Humax 9200T? It now aborts with "ERROR: Source video packet size is 188 bytes, must be 192."
You need the hrwconv package to simplify this, if the files are already on the Humax.
 

prpr

Well-Known Member
IIRC when I copied the TSs from my 9200 to my T2, they 'just worked' providing you don't want the fancy stuff.
You do RC, but clearly the OP does want proper transport controls, otherwise he wouldn't be here asking about sidecar would he?
 
You need the hrwconv package to simplify this, if the files are already on the Humax.
Can this work even if I only have the old 9200T .ts files without their original sidecars? The package notes seem to imply that they're needed.

You're right about proper transport controls. I was upset when I first got my T2 to find that recorded radio's play controls had been butchered: no fast-forward or back. The old 9200T had them, so I don't understand why Humax cut them out. It's a real nuisance when the BBC front-load recordings with a minute or more of trails.
 

prpr

Well-Known Member
Can this work even if I only have the old 9200T .ts files without their original sidecars? The package notes seem to imply that they're needed.
Yes, it does work. The original 9200 sidecars are optional, not required.
I don't understand why Humax cut them out.
I expect they thought that dumbing down the interface would make it simpler for people. Of course, it doesn't, it just annoys those who used the facility. Those who didn't use it didn't care whether it was there or not. I expect it was some clueless Humax bean-counter somewhere trying to save money/development time. All they succeeded in doing was making things inconsistent.
It's a real nuisance when the BBC front-load recordings with a minute or more of trails.
Programmes don't start exactly on time like they should do for telly. It's just done on a clock schedule.
 
Yes, it does work. The original 9200 sidecars are optional, not required.
I managed to get it to work after some misadventures. I had trouble navigating to the directory with the .ts files because I'd forgotten the "ls" command and also fell foul of linux's case sensitivity and inability to handle the space in "My Video". The hrwconv package worked, albeit with some intermittent error messages. But it was very slow, so I'll probably stick with the tsMuxeR/Sidecar combination on the PC.

Getting the full transport controls was useful, but my main reason for converting the files is to process them with detectads.
 
OP
OP
R

raydon

Well-Known Member
I have just released sidecar v2.5. This version has some refinements to the way the nts 'Played time' entry at offset 0x18 is calculated. Previous versions used a calculation based solely on PES PTS values (which do not always increase monotonically)
To account for this, v2.4 simply used repeat values when the current PTS value was less than that in the previous one.
This version uses a combination of both PTS and DTS values to derive more accurate monotonically increasing values for the timebar.
Wiki links for Linux and Windows versions have been updated accordingly.
 
Last edited:
I have just released sidecar v2.5. This version has some refinements to the way the nts 'Played time' entry at offset 0x18 is calculated. Previous versions used a calculation based solely on PES PTS values (which do not always increase monotonically)
To account for this, v2.4 simply used repeat values when the current PTS value was less than that in the previous one.
This version uses a combination of both PTS and DTS values to derive more accurate monotonically increasing values for the timebar.
Wiki links for Linux and Windows versions have been updated accordingly.
Thanks for the sidecar updates.
I had noticed with earlier versions of sidecar that the nts files created for recordings (H264 video) that had been remuxed with ffmpeg had unusually large values corresponding to the offset at 0x18 (onscreen time bar value) for some early frames (typically 2-9 frames). Since the latest update, the first frame of ffmpeg-remuxed MPEG video also gets assigned a large value in the nts file at offset 0x18. I made short recordings of H264 and MPEG streams and remuxed both 'on-the-box' with stream copying, and have attached example nts files below. The original recordings are unaffected, so it must be something that ffmpeg does that causes this. I appreciate that sidecar works as intended for native recordings, but thought I'd mention it as packages like hrwconv use both ffmpeg and sidecar. It is easy to fix the files with a hex editor, by setting the affected values to zero.
 

Attachments

OP
OP
R

raydon

Well-Known Member
Thanks for the sidecar updates.
I had noticed with earlier versions of sidecar that the nts files created for recordings (H264 video) that had been remuxed with ffmpeg had unusually large values corresponding to the offset at 0x18 (onscreen time bar value) for some early frames (typically 2-9 frames). Since the latest update, the first frame of ffmpeg-remuxed MPEG video also gets assigned a large value in the nts file at offset 0x18. I made short recordings of H264 and MPEG streams and remuxed both 'on-the-box' with stream copying, and have attached example nts files below. The original recordings are unaffected, so it must be something that ffmpeg does that causes this. I appreciate that sidecar works as intended for native recordings, but thought I'd mention it as packages like hrwconv use both ffmpeg and sidecar. It is easy to fix the files with a hex editor, by setting the affected values to zero.
@MontysEvilTwin Thanks for that information. It seems that I inadvertently introduced a bug into that last version which caused the problem you saw with ffmpeg remuxed video. I've just uploaded sidecar v2.6 to the repository, which hopefully will have fixed it. Can you confirm ? Wiki links to other OS versions updated also.
Oops. I left a temporary debug message in v2.6. Now on v2.7 :rolleyes:
 
Last edited:
@MontysEvilTwin Thanks for that information. It seems that I inadvertently introduced a bug into that last version which caused the problem you saw with ffmpeg remuxed video. I've just uploaded sidecar v2.6 to the repository, which hopefully will have fixed it. Can you confirm ? Wiki links to other OS versions updated also.
Oops. I left a temporary debug message in v2.6. Now on v2.7 :rolleyes:
I tested with the same remuxed recordings I used previously, now with v2.6, and it was fine with both MPEG and H264 video. I'll do a bit more testing and will post if I get any unexpected results. Thanks for the fix.
 
I did some further tests with longer recordings (up to about 1 hour 40 minutes, remuxed with ffmpeg) using sidecar 2.7. The nts files created for MPEG video recordings are fine, as far as I can tell. There is still a problem with H264 video though. In the example attached (recording of about 58 minutes), the values corresponding to the on-screen time bar start to be set to a high value (2359b005 in this case) later on in the recording (first example at offset 0x0053bbd8). This happens about every other frame for a while and then less frequently until the end. I had to split the nts file to allow me to post all of it. The second part is in the next message. It can be recombined using the 'cat' command after extracting the files from the zip files.
 

Attachments