[VU+ Duo2] IPTV timers crash

[bbbuk]

I'm unable to re-produce this....

Setup and settings:
Solo2 with a couch flash to version (031 and 032) with only things restored was actual settings file itself (manually transferred) and slight amendments to ABM code so it changes IPTV streams service reference from default 1 to 4097. ABM settings are local SD region and removed code from provider file that so it only swaps the FTA (1-5) channels. Then used @Huevos custommix option to replace IPTV streams with dark channels. No other settings where changed nor was any plugin installed except what is installed by default with basic image.

How tried to re-produce it:
Did usual ABM scan and from live TV pressed Rec button on remote and selected the first option (record until end of event). No crash. Did this on several IPTV streams and on normal DVB streams.

Then form GEPG screen, highlighted an IPTV stream and pressed Rec button to add timer. Again no crash.

I then, from my slightly modded ABM, changed settings so that it uses service type 1 (normally I use 4097) for IPTV streams and did the above steps. Again, no crash.

Before recording, I checked Info > Service to confirm that service reference began with either a 1 or 4097 and was in fact an IPTV stream.

My thoughts...

This doesn't, at least that I can tell, to be easily re-produced at least during tests and I don't even remember reading how OP got it to crash? Was it via pressing Rec button as I mentioned or was it via an autotimer?

What is service type in use and is ServiceApp installed so it potentially uses another player rather than dvb/gstreamer or something else that is changing IPTV stream?

 

[ccs]

OP just says "IPTV timers crash", a crash log was submitted but removed.

 

[bbbuk]

OP just says "IPTV timers crash"...

That's point. Very little information to go on even to try to re-produce it.

Have any mods/vix team members able to re-produce this?

a crash log was submitted but removed.

That may have been because OP had left in IPTV URL of provider.

 

[abu baniaz]

I removed the debug log because debug log had IP address, username and password. In hindsight, I should have edited it.

Sorry.

 

[Huevos]

Yes there is a debug log, but there is no recipe and no confirmation. That means you are suggesting a fix with no way of testing the fix. And no, hiding an error rather than fix it is not a good plan.

 

[birdman]

And no, hiding an error rather than fix it is not a good plan.

And I'm arguing that fix I've provided is to change a generic test (is it not None) to a specific test (is it an int, as that is what we wish to use) and hence is the code which should have been put there in the first place.

This is exactly why enigma code is in such a mess.

I reckon that the biggest problem is the lack of documentation, particularly about the API.
When I submitted patches (before I submitted PRs) I often found the comments I'd added, so that the next reader of the code has some quick idea of what was/should be going on, where removed in the actual submission.

 

[birdman]

Have any mods/vix team members able to re-produce this?.

Not that I know of, but it has been reported by two users.
It's also reported to be a 5.1.030 to 5.1.031 regression.

 

[Huevos]

And I'm arguing that fix I've provided is to change a generic test (is it not None) to a specific test (is it an int, as that is what we wish to use) and hence is the code which should have been put there in the first place.

Gordon, no point arguing about this. Tuner_number should contain an int, or not exist. If it does not the underlying code is wrong and needs fixing. Testing that it contains an int is just a way to mask the problem, which will just pop up somewhere else when that variable is used by another piece of code.

"is not None" is used because that is what ".get" returns for a key that is not set.

 

[birdman]

It's also reported to be a 5.1.030 to 5.1.031 regression.

Although that will be because the tuner logging code only went in at 5.1.031.
Likely that the underlying issue has always(?) been there.

 

[birdman]

.... but normally I would expect Birdman to provide some code to those that can reproduce it, to display what is in the field - and then maybe we can find why it is being corrupted and by what..... just a suggestion

OK.

This copy of RecordTimer.py:

View attachment RecordTimer.zip

contains my change (so the recording shouldn't crash) but will print some info to the debug log if it finds that it has a tn variable which is not None and also not an int.

So if someone who is seeing the crash can

• unzip this file
• put it into /usr/lib/enigma2/python/ on their box
• take a backup copy of the RecordTimer.pyc file which is already there (so that you can revert...)
• restart the GUI (or reboot the box)
• set a timer that would cause the crash
• let it run
• look at the debug log covering the timer start and look for a line containing:
  "[RecordTimer - DEBUG] Odd tn seen"
• post that and the lines which follow it

it might help to track down the problem.

 

[Huevos]

This is an odd way to get a bug report. Hide the error and hope people look for a problem in the logs.

 

[ccs]

This is an odd way to get a bug report. Hide the error and hope people look for a problem in the logs.

The error isn't being hidden, a crash is being avoided, and debug logging created, it makes sense to me.

And as no one else can reproduce it, apart from 2 posters on this thread "So if someone who is seeing the crash can..." makes sense to me as well.

 

[birdman]

This is an odd way to get a bug report. Hide the error and hope people look for a problem in the logs.

It's not hiding the error: it's avoiding the symptoms.

 

[Ev0]

Not sure how much of a log you need.

But with using birdmans file, this is from my debug log:

< 78828.461> [eDVBServiceRecord] start recording...< 78828.461> [eDVBServiceRecord] getting program info failed.
< 78828.462> [RecordTimer] start recording on tuner: ?
< 78828.462> [RecordTimer - DEBUG] Odd tn seen
< 78828.462> type: <type 'dict'>
< 78828.462> value: {}
< 78828.513> [Task] job Components.Task.Job name=Cleaning Trashes #tasks=1 completed with [] in None
< 78828.632> [eHttpStream] Thread end connection
< 78828.642> [eInputDeviceInit] 0 18f 1
< 78828.645> [InfoBarGenerics] KEY: 399 GREEN
< 78828.703> [eFilePushThread] wait for driver eof timeout
< 78828.749> [eDVBServicePMTHandler] PATready
< 78828.749> [eDVBServicePMTHandler] use single pat entry!
< 78828.749> [eDVBServicePMTHandler] use pmtpid 0fff for service_id 0001
< 78828.749> [eDVBDemux] open demux /dev/dvb/adapter0/demux1
< 78828.749> [eDVBSectionReader] DMX_SET_FILTER pid=4095
< 78828.750> [eDVBDemux] open demux /dev/dvb/adapter0/demux1
< 78828.750> [eDVBSectionReader] DMX_SET_FILTER pid=0
< 78828.750> [eDVBServiceRecord] RECORD service event 5
< 78828.750> [eDVBServiceRecord] start recording...
< 78828.751> [eDVBServiceRecord] RECORD: have 1 video stream(s) (00d3), and 1 audio stream(s) (00dd), and the pcr pid is 00d3, and the text pid is ffffffff
< 78828.751> [eDVBServiceRecord] ADD PID: 0000
< 78828.751> [eDVBServiceRecord] ADD PID: 00d3
< 78828.751> [eDVBServiceRecord] ADD PID: 00dd
< 78828.751> [eDVBServiceRecord] ADD PID: 0fff
< 78828.752> [setIoPrio] realtime level 7 ok
< 78828.752> [eFilePushThreadRecorder] THREAD START

 

[birdman]

Not sure how much of a log you need.

Thanks - that's sufficient.
I wanted to know the contents of the dict that it claims to have (where it should be able to get only an int or None). Oddly, it's empty.

Did the timer actually work after this?

 

[Ev0]

Yes it did.

Huevos has fixed it now though using a log I sent him.

 

[Huevos]

As far as I can see we should be able to simplify to this (if anyone can test).

# Report the tuner that the current recording is using
	def log_tuner(self, level, state):
		feinfo = self.record_service and self.record_service.frontendInfo()
		tn = feinfo and feinfo.getFrontendData().get("tuner_number")
		tuner_info = tn is not None and chr(ord('A') + tn) or "?"
		self.log(level, "%s recording on tuner: %s" % (state, tuner_info))

 

[Ev0]

As far as I can see we should be able to simplify to this (if anyone can test).

# Report the tuner that the current recording is using
    def log_tuner(self, level, state):
        feinfo = self.record_service and self.record_service.frontendInfo()
        tn = feinfo and feinfo.getFrontendData().get("tuner_number")
        tuner_info = tn is not None and chr(ord('A') + tn) or "?"
        self.log(level, "%s recording on tuner: %s" % (state, tuner_info))

That also seems to work

 

[birdman]

As far as I can see we should be able to simplify to this (if anyone can test).

# Report the tuner that the current recording is using
    def log_tuner(self, level, state):
        feinfo = self.record_service and self.record_service.frontendInfo()
        tn = feinfo and feinfo.getFrontendData().get("tuner_number")
        tuner_info = tn is not None and chr(ord('A') + tn) or "?"
        self.log(level, "%s recording on tuner: %s" % (state, tuner_info))

So the change is (effectively) that tn will be None if feinfo.getFrontendData() is empty (or, actually, {}).

 

[Huevos]

Yes.

TBH Gordon I think I screwed up in the first attempt. I thought feinfo.getFrontendData() would return None if not populated, where it seems it always contains a Dict. Reading the CPP layer code should confirm this... but be aware there are two different functions named getFrontendData(), one takes a Python Dict as the first argument and the other is this one with no arguments. No idea who thought it would be a good idea to have 2 functions that did similar things and name them the same, adding to confusion for anyone trying to read the code at a later stage.

So if my assumption that getFrontendData() will always return a Dict is correct the code you quoted in your post should be good. And the code currently in the git should be fine either way. What baffles me though is I thought this had been tested for IPTV and didn't crash.