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

raydon,

Many thanks for the update and thank you for mentioning the BST flag in the hmt file. I realised there was probably such a flag but I hadn't been able to find it, in spite of examining sample hmt files from the HDR (my eyes must have glazed over and missed it).

As I have been doing a lot of conversions of old recordings (obtained via a USB DVB tuner stick) I wrote a quick and dirty VB macro in Excel to pick up the Channel, Genre, Synopsis, date and bookmarks from a list on an Excel worksheet - thinking that it would be more convenient and save time. When I take into account the time spent debugging and checking that it worked correctly it probably didn't actually save any time at all - but I learnt a great deal in the process!
 
raydon,
When I take into account the time spent debugging and checking that it worked correctly it probably didn't actually save any time at all - but I learnt a great deal in the process!
Most "short cuts" end up that way!
 
Yup. Sometimes it is best to just get on with it, and not waste getting-on-with-it time looking for a better way. Not that I am very good at taking this particular advice myself.

Many, many years ago I was reading Stonehenge Decoded by Gerald S Hawkins. He described writing a program to calculate the azimuths of all the stones from all the other stones, and then waiting months for computer time to run it, when I figured it could be done quite easily in a few hours with a scientific calculator.
 
Sidecar package now updated to v1.9.
Improved the sync byte detection as the original check could throw up false positives for 188 byte packets streams under certain circumstances.
 
raydon,

Sorry to be a pain in the backside but should the Linux download version of sidecar 1.9 be named "sidecar_1.9_mipsel.opk" (which it is) or is it possible that this is the package intended for the Humax?

Thanks for all your good work!
 
Link is OK now. Sorry about that, in my haste I uploaded the wrong file. Would have corrected it last night but my social life took priority. And, judging by Ezra's typing, he had a few glasses last night too !
 
Yes, it did resemble a translation from a Chinese user manual (now corrected), I think I needed a early night :)
 
The 'sidecar' package is now updated to v2.0 to include the mod suggested by prpr. Thanks to prpr for this suggestion.
The mod enables the creation of a dummy hmt file for an encrypted recording when the original sidecar file(s) are missing. This allows the recording to be decrypted, thus enabling a valid hmt (and nts if required) to be later created from the now decrypted recording. Sidecar can now also create a zero length dummy nts file if there isn't one already. An nts file of some sort is required to enable the 'Decrypt' option to be available in the Opt+ dropdown menu. Users may note that when a dummy hmt file is created, the recording is flagged with the 'Shrunk' icon in the media list. This is purely to disable the 'Opt+/Shrink' option when using a dummy hmt file. Once a valid hmt is created from the decrypted recording this will reflect the true status.
sidecar.png
 
Last edited:
If you're in the mood for sidecar updates, could it update the recording length in the hmt file when it generates a new nts file? Then if you edit out ads off-box, overwrite the ts file with the new shorter version and generate a new nts file, the timeline displayed when using the arrow keys on the remote will be accurate.
 
Is this a mood thing or some technical problem or a distaste thing?:unsure:
Something to conciser when making a request to package developers and other contributors to this forum is that is is just that, a request. I'm sure most users of this forum have worked for (or with) someone who uses the 'Just F***ing Do It' method of persuading his / her colleges to do something, but you have to remember these people are giving their time free of charge. Like quite a few other users I have suggested addition, modifications, etc to packages and some of them have been implemented, others have not, at the end of the day developers do what they want to do, so I would say that it doesn't really matter which of these is the answer to your question :-

1) It is not possible to do what you are asking
2) It probably is possible, but it would be very time consuming and I'm not prepared to do it
3) It is possible to do it, but I don't want my package to do that
 
at the end of the day developers do what they want to do, so I would say that it doesn't really matter which of these is the answer to your question :-

1) It is not possible to do what you are asking
2) It probably is possible, but it would be very time consuming and I'm not prepared to do it
3) It is possible to do it, but I don't want my package to do that

Whilst I understand the point you're making, I would respectfully disagree, in that there may be some use in knowing which is the answer, at least in some cases.

e.g. if the answer were 2), I might then choose to offer the pkg developer a contribution, perhaps either cash, or an offer of doing some of the work.

For the other answers, a more detailed reply, i.e. as to why it's not possible, or undesirable, might be technically interesting, and prove educational for the person asking, which does not seem out of place in a discussion forum.
 
Whilst I understand the point you're making, I would respectfully disagree, in that there may be some use in knowing which is the answer, at least in some cases.

e.g. if the answer were 2), I might then choose to offer the pkg developer a contribution, perhaps either cash, or an offer of doing some of the work.

For the other answers, a more detailed reply, i.e. as to why it's not possible, or undesirable, might be technically interesting, and prove educational for the person asking, which does not seem out of place in a discussion forum.
To imply that mood or distaste somehow influences my decision making, just because a request is rejected does nothing to encourage me, in fact the exact opposite applies.
My purpose in providing this utility was never financial gain, so the suggestion that a cash incentive might spur me into action is insulting. Nor have I solicited, or require any help.
I will not be intimidated, bullied, or otherwise humiliated into entering into long winded technical discussions, purely to justify to others the decisions I make. I have neither the time or the inclination.
 
Last edited:
Whilst I understand the point you're making, I would respectfully disagree, in that there may be some use in knowing which is the answer, at least in some cases.

e.g. if the answer were 2), I might then choose to offer the pkg developer a contribution, perhaps either cash, or an offer of doing some of the work.

For the other answers, a more detailed reply, i.e. as to why it's not possible, or undesirable, might be technically interesting, and prove educational for the person asking, which does not seem out of place in a discussion forum.

While I agree with your comments to a certain extent, I would say that, just as a developer has the option to implement (or not implement) a request for a change to his package, he also has the right to explain (or not to explain), the reasons why. You can't demand an answer, it is not uncommon to get no answer at all, in which case the OP wouldn't have even received #73
 
Last edited:
Back
Top