Black Cloud
Member
For what it's worth, I can confirm that the automatic start and stop information for Death In Paradise was broadcast okay on BBC 1 HD in the London area.
HDR-FOX T2 to HDHomeRun, my journey
- Thread starter lc200
- Start date
Hi, had a look in the eventlog, it did start recording for Death in Paradise however it never seemed to obtain the PMT data so never started recording the stream for that program, that data is broadcast continually so I'm thinking some corruption caused that bit of the code to exit without completing. I will have a look at the code and see if I can find where it might have gone wrong and how it might recover better.
NBhummyuser
Member
Hi thankyou for taking a look
Regards nick
Regards nick
Had a look at the code to try and see what might have happened. It appears when the tuner was asked to filter and return the packets with the ID 100, which in turn identifies all the packets required to be pulled from the MUX in order to save the program, the tuner went quiet and never returned the required packets of data. I can't say why that would be as it would have happened upstream from the code. I will add some debug code and see if I can make it self recover if it doesn't get any packets from the tuner having requested them after a few seconds. It might be worth while enabling the debug logs in case you get something similar again as that will capture more info from the tuner commands and responses.
NBhummyuser
Member
There seems to be a problem with the drama channel . It claims to start recording but doesn't stop and produces no file. This has happened to me several times now. Hopefully you can help I set up a test with debug turned on log file attached.
prpr
Well-Known Member
For the record, the transmission events were OK (as received here):
19 23:15:17 Event 16208:58289 4F:28 started 23:15:00 01:20:00 "Luther" /QQK9LS
20 00:34:57 Event 16208:57888 4F:29 started 00:35:00 01:20:00 "Happy Valley" /C46FK4 /ebsuktv54447
20 01:53:45 Event 16208:58191 4F:30 started 01:55:00 00:50:00 "Leonardo" /QQKBMX
Thanks for the debug log, it seems to be a continuation of the same problem where it isn't obtaining the data required from the transport stream in order to know which packets to record so it doesn't record anything. I do have some time this week so will do some changes and get a test version to you. I'm suspecting the tuner isn't receiving the command and some small packets are getting dropped. Is it a wired network or is DvrOnTime connected via Wi-Fi?
NBhummyuser
Member
Thanks for taking a look. It it is a wired network with a couple of gb switches between pc & the tuner. Recordings on other channel seem to be ok just the drama channel..
prpr: How do you get the transmission events,?
Nick B
prpr: How do you get the transmission events,?
Nick B
prpr
Well-Known Member
I wrote my own software to decode EITpf (and several other things) and log the changes.
NBhummyuser
Member
Does your software use an specific transmitter? I am using the mendip transmitter
prpr
Well-Known Member
No. It decodes whatever is fed to it from whichever transmitter channel I have tuned (currently PSB3). It makes little difference as all the service info. is delivered to all muxes for all services contained therein (and for regionalised adjacent area services - the things you learn when you start observing!).
There is potentially a small time delay (a very few seconds) if it's for a service on a mux which isn't the current tuned one.
Likewise.
Just to add the EIT isn't the problem with your non-recordings, the EIT is read correctly and the recording is set to start. The problem appears to be some issue with the tuner not starting correctly when its ask to return other packets. I can't replicate the problem but I'm adding a watch dog timer that will identify a stalled tuner and will restart it, along with better recovery from a network problems. Hopefully can get something to you today or tomorrow to test with and see if that resolves the issues you are experiencing.