Modify

Opened 9 years ago

Closed 6 years ago

Last modified 6 years ago

#5739 closed defect (Fixed)

EITScanner randomly stops

Reported by: mythtv@… Owned by: janne
Priority: major Milestone:
Component: MythTV - EIT Version: head
Severity: medium Keywords: eitscanner eithelper epg
Cc: Ticket locked: yes

Description

My EPG data stops to add new events a short while after backend has been started. Don't know how to debug or give more exact information on this, but I have to restart the backend atleast once a week.

I have EIT,VBI logging on and did see today that EITScanner(3) stopped yesterday and only EITScanner(1) runs now.

I live in Finland, Vaasa reading DVB data from VLP cable network using 2 DVB-C cards with 2 virtual tuners each.

I have had this problem for many months now, thought someone would find and fix it by now though.

Attachments (2)

EPG.png (41.7 KB) - added by Floppe 9 years ago.
EPG 6 days ahead
eitscan_channelchange_may_fail.diff (512 bytes) - added by janne 9 years ago.
setchannel failing is not a fatal error during active eitscan

Download all attachments as: .zip

Change History (49)

comment:1 Changed 9 years ago by Dibblah

Hi,

Can you please attach a full log of

mythbackend -v channel,record,eit

for the period from startup until EIT data is no longer being collected?

Cheers,

Allan.

comment:2 Changed 9 years ago by Dibblah

  • Status changed from new to infoneeded_new

Changed 9 years ago by Floppe

EPG 6 days ahead

comment:3 Changed 9 years ago by mythtv@…

Now, one day after I started the logging you can already see in the EPG 6 days ahead (we get 7 days of EPG in our network) that there are glitches. Usually if I wait 6-7 days there are almost nothing left in the EPG so I'm forced to restart the backend.

The log is over 1MB gzipped so I placed it on a web server for now.

http://213.250.69.122/mythbackend.log.gz

comment:4 Changed 9 years ago by Dibblah

Hi,

This will make your logs much larger, but could you also add siparser to your verbose flags?

I do see that events in that log are getting added until the log ends, so it looks like either the data is invalid or your provider only transmits long-term EIT data on one multiplex.

Cheers,

Allan.

comment:5 Changed 9 years ago by mythtv@…

Hello,

I turned on the flag and here is the log for about a hour in use. I left it running if you need more data. Really much CRC errors.

http://213.250.69.122/mythbackend.log.2.gz

Floppe

comment:6 Changed 9 years ago by Dibblah

It looks to me like your CAM is rewriting the stream with incorrect CRCs. It is also possible that Myth is calculating a checksum for a packet type that doesn't have one.

Can you try manually applying the following hack:

--- libs/libmythtv/mpeg/pespacket.cpp	(revision 18370)
+++ libs/libmythtv/mpeg/pespacket.cpp	(working copy)
@@ -171,6 +171,7 @@
                         "for StreamID = 0x%3")
                 .arg(CRC(),0,16).arg(CalcCRC(),0,16).arg(StreamID(),0,16));
     }
+    ret=true;
     return ret;
 }

Then see if the EIT data fills better?

WARNING: This is a hack and disables CRC checking - So there is a possibility that you will see corrupted guide data. Back up your database first!

comment:7 Changed 9 years ago by janne

  • Milestone changed from unknown to 0.21.1
  • Status changed from infoneeded_new to new

The crc errors are unrelated. The EITScanner (3) in the first log stops, when it tries to tune (and fails) during a recording is made on a virtual recorder on the same real card.

comment:8 Changed 9 years ago by janne

  • Owner changed from ijr to janne
  • Status changed from new to accepted

Changed 9 years ago by janne

setchannel failing is not a fatal error during active eitscan

comment:9 Changed 9 years ago by janne

  • Status changed from accepted to started

please try http://svn.mythtv.org/trac/attachment/ticket/5739/eitscan_channelchange_may_fail.diff

The error triggers if there is a recording on a virtual card and active eitscan is running on the first card.

comment:10 follow-up: Changed 9 years ago by mythtv@…

Seems like Janne's patch did fix the mystical disappearance of EITScanner (3). At least for now its still running. But the EPG is still not updated.

Some questions. Why is there no more CRC errors after 2008-09-27 02:59:57.813, could something have crashed there? And EITCache loaded entries are not logged anymore after 2008-09-26 16:00:10.

Should I try Dibblah's hack? If it screws up something, is it enough to only empty program and eitcache tables in MySQL?

http://213.250.69.122/mythbackend.log.3.gz

Floppe

comment:11 follow-up: Changed 9 years ago by i.dobson

I'm seeing exactly the same problem with 2xDVB-C cards. Backend log contains:-

2008-09-27 13:27:18.007 EITScanner (5): Added 18 EIT Events 2008-09-27 13:27:18.352 TVRec(5) Error: Failed to set channel to 30417. Reverting to kState_None 2008-09-27 13:27:18.420 EITScanner (5): Now looking for EIT data on multiplex of channel 30417

or

2008-09-28 10:03:24.316 DTVSM(0) Error: Wrong PMT; pmt->pn(31210) desired(30413) 2008-09-28 10:03:24.531 Program #30413 not found in PAT! Program Association Table PSIP tableID(0x0) length(57) extension(0x25f) version(4) current(1) section(0) last_section(0) tsid: 607 programCount: 12 program number 0 has PID 0x 10 data 0x 0 0x 0 0xe0 0x10 program number 31201 has PID 0x 64 data 0x79 0xe1 0xe0 0x64 program number 31202 has PID 0x 6e data 0x79 0xe2 0xe0 0x6e program number 31203 has PID 0x d2 data 0x79 0xe3 0xe0 0xd2

comment:12 in reply to: ↑ 11 Changed 9 years ago by janne

Replying to i.dobson:

I'm seeing exactly the same problem with 2xDVB-C cards. Backend log contains:-

2008-09-27 13:27:18.007 EITScanner (5): Added 18 EIT Events 2008-09-27 13:27:18.352 TVRec(5) Error: Failed to set channel to 30417. Reverting to kState_None 2008-09-27 13:27:18.420 EITScanner (5): Now looking for EIT data on multiplex of channel 30417

this one is fixed by the patch which should be committed in a minute

2008-09-28 10:03:24.316 DTVSM(0) Error: Wrong PMT; pmt->pn(31210) desired(30413) 2008-09-28 10:03:24.531 Program #30413 not found in PAT! Program Association Table PSIP tableID(0x0) length(57) extension(0x25f) version(4) current(1) section(0) last_section(0) tsid: 607 programCount: 12 program number 0 has PID 0x 10 data 0x 0 0x 0 0xe0 0x10 program number 31201 has PID 0x 64 data 0x79 0xe1 0xe0 0x64 program number 31202 has PID 0x 6e data 0x79 0xe2 0xe0 0x6e program number 31203 has PID 0x d2 data 0x79 0xe3 0xe0 0xd2

your channel information looks outdated, please rescan

comment:13 in reply to: ↑ 10 ; follow-up: Changed 9 years ago by janne

Replying to mythtv@floppe.eu.org:

Seems like Janne's patch did fix the mystical disappearance of EITScanner (3). At least for now its still running. But the EPG is still not updated.

I'll commit the patch.

Some questions. Why is there no more CRC errors after 2008-09-27 02:59:57.813, could something have crashed there?

The CRC errors are unrelated and cause no harm except log spam.

And EITCache loaded entries are not logged anymore after 2008-09-26 16:00:10.

I don't think that's a problem as long as new events are added. The problem of missing entries in the future remains?

Should I try Dibblah's hack? If it screws up something, is it enough to only empty program and eitcache tables in MySQL?

It won't change anything but clearing the program and eitcache table is enough to clear and recreate the program information.

comment:14 Changed 9 years ago by janne

(In [18500]) EITScan tuning request may fail but we do not care. Refs #5739

comment:15 Changed 9 years ago by janne

(In [18501]) EITScan tuning requests may fail we do not care.

backports [18500] from trunk. Refs #5739

comment:16 in reply to: ↑ 13 Changed 9 years ago by anonymous

Replying to janne:

I don't think that's a problem as long as new events are added. The problem of missing entries in the future remains?

Problem remains.

I've removed my CAM completly as I only have 3 scrambled channels which I don't need this weekend. Seems like the problem still remains with missing entries.

comment:17 Changed 9 years ago by i.dobson@…

Hi,

I'm still seeing random EIT scanner deaths.

2008-10-06 DVBChan(5:0) Error: SetChannelByString?(30418): Input is not available
2008-10-06 TVRec(5) Error: Failed to set channel to 30418. Reverting to kState_None
2008-10-06 EITScanner (5): Now looking for EIT data on multiplex of channel 30418
2008-10-06 EITCache: Pruning all entries that ended before UTC 2008-10-05T14:25:31[[BR]] 2008-10-06 EITCache: Deleting old cache entries from the database

Regards Ian Dobson

comment:18 Changed 9 years ago by mythtv@…

Hello again,

I can confirm that EIT scanner deaths are still there.

Here's a snippet from the log file where EITScanner (3) is last seen.

2008-10-07 07:20:27.022 DVBChan(3:3): SetChannelByString(40):
2008-10-07 07:20:27.033 DVBChan(3:3) Error: SetChannelByString(40): Multiplex is not available
2008-10-07 07:20:27.056 TVRec(3) Error: Failed to set channel to 40. Reverting to kState_None
2008-10-07 07:20:27.061 TVRec(3): Request: Program(no) channel() input() flags(KillRec,)
2008-10-07 07:20:27.088 TVRec(3): ClearFlags(EITScannerRunning,) -> RunMainLoop,
2008-10-07 07:20:27.103 TVRec(3): ClearFlags(PENDINGACTIONS,) -> RunMainLoop,
2008-10-07 07:20:26.971 PIDInfo(3): Closing filter for pid 0x11
2008-10-07 07:20:27.104 TVRec(3): SetChannel(40) -- end
2008-10-07 07:20:27.111 EITScanner (3): Now looking for EIT data on multiplex of channel 40
2008-10-07 07:20:27.112 EITCache: Pruning all entries that ended before UTC 2008-10-06T07:25:29
2008-10-07 07:20:27.135 EITCache: Deleting old cache entries from the database

And I started to watch livetv 10 seconds earlier (if that could be the reason).

2008-10-07 07:20:16.482 TVRec(4): Changing from None to WatchingLiveTV
2008-10-07 07:20:16.491 TVRec(4): ClearFlags(FrontendReady,CancelNextRecording,) -> RunMainLoop,RingBufferReady,
2008-10-07 07:20:16.501 TVRec(4): Request: Program(no) channel() input() flags(LiveTV,)
2008-10-07 07:20:16.511 TVRec(4): Start channel: 10.
2008-10-07 07:20:16.525 TVRec(4): HW Tuner: 4->4
2008-10-07 07:20:16.532 TVRec(4): ClearFlags(PENDINGACTIONS,) -> RunMainLoop,RingBufferReady,
2008-10-07 07:20:16.542 TVRec(4): No recorder yet, calling TuningFrequency
2008-10-07 07:20:16.551 DVBChan(4:3): Opening DVB channel
2008-10-07 07:20:16.561 DVBChan(4:3): SetChannelByString(10):

Floppe

comment:19 Changed 9 years ago by paulh

  • Component changed from mythtv to eit

comment:20 Changed 9 years ago by stuartm

  • Milestone changed from 0.21.1 to 0.22

comment:21 Changed 9 years ago by janne

  • Status changed from started to accepted
  • Summary changed from EITScanner to EITScanner randomly stops

deprecated started state

comment:22 Changed 8 years ago by stuartm

  • Component changed from eit to MythTV - EIT

comment:23 Changed 8 years ago by janne

  • Milestone changed from 0.22 to 0.23

pushing to 0.23 since I can't reproduce it

comment:24 Changed 8 years ago by janne

  • Resolution set to fixed
  • Status changed from accepted to closed

please reopen if it's still an issue

comment:25 follow-up: Changed 8 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to new

Hi,

I didn't notice this ticket before, but I have this issue as well. I need to restart the backend at least once a week to get the EPG data. I guess the EPG data collecting stops within the first 24h after backend has been started. I live in Finland, just like the person who created this ticket.

I've been using mythtv from 0.21_beta16340 to 0.22_p23069 and this problem has always been present. My workaround has been a cronjob to restart mythbackend every now and then.

Samppa

comment:26 in reply to: ↑ 25 ; follow-up: Changed 8 years ago by TomiL

Replying to anonymous:

Hi,

I didn't notice this ticket before, but I have this issue as well. I need to restart the backend at least once a week to get the EPG data. I guess the EPG data collecting stops within the first 24h after backend has been started. I live in Finland, just like the person who created this ticket.

I've been using mythtv from 0.21_beta16340 to 0.22_p23069 and this problem has always been present. My workaround has been a cronjob to restart mythbackend every now and then.

Samppa

Same problem here as well. I started from 0.20 and still same problem with 0.22 (lastes official ubuntu 9.10-version, sorry can't remember correct number). It seems thta EIT works only one week roughly and then stop. Restarting backend fix this issue for next week. I am living in Tampere/Finland? using TTV-cable.

br, Tomi

comment:27 in reply to: ↑ 26 ; follow-up: Changed 8 years ago by otto at kolsi dot fi

Replying to TomiL:

I didn't notice this ticket before, but I have this issue as well. I need to restart the backend at least once a week to get the EPG data. I guess the EPG data collecting stops within the first 24h after backend has been started. I live in Finland, just like the person who created this ticket.

I've been using mythtv from 0.21_beta16340 to 0.22_p23069 and this problem has always been present. My workaround has been a cronjob to restart mythbackend every now and then.

Samppa

Same problem here as well. I started from 0.20 and still same problem with 0.22 (lastes official ubuntu 9.10-version, sorry can't remember correct number). It seems thta EIT works only one week roughly and then stop. Restarting backend fix this issue for next week. I am living in Tampere/Finland? using TTV-cable.

br, Tomi

I've been using Myth with DVB-T in Finland >4 years and never had this kind of problems. Could it be DVB-C related, or related to particular card?

comment:28 in reply to: ↑ 27 ; follow-up: Changed 8 years ago by TomiL

Replying to otto at kolsi dot fi:

Replying to TomiL:

I didn't notice this ticket before, but I have this issue as well. I need to restart the backend at least once a week to get the EPG data. I guess the EPG data collecting stops within the first 24h after backend has been started. I live in Finland, just like the person who created this ticket.

I've been using mythtv from 0.21_beta16340 to 0.22_p23069 and this problem has always been present. My workaround has been a cronjob to restart mythbackend every now and then.

Samppa

Same problem here as well. I started from 0.20 and still same problem with 0.22 (lastes official ubuntu 9.10-version, sorry can't remember correct number). It seems thta EIT works only one week roughly and then stop. Restarting backend fix this issue for next week. I am living in Tampere/Finland? using TTV-cable.

br, Tomi

I've been using Myth with DVB-T in Finland >4 years and never had this kind of problems. Could it be DVB-C related, or related to particular card?

Might be, I never had this problem with 0.18 and 0.19 but problem start with 0.20. Also my friend have same issue, we both have cable-card, Technotrend c1500 and both using TTV-cable. We both using ubuntu, different verison. I have tried ubuntu 8.04, 8.10, 9.04 and 9.10 without success.

I just checked my myth version and it is 0.22-fixes (22594)

br, Tomi

comment:29 in reply to: ↑ 28 ; follow-up: Changed 8 years ago by anonymous

Replying to TomiL:

Replying to otto at kolsi dot fi:

Replying to TomiL:

I didn't notice this ticket before, but I have this issue as well. I need to restart the backend at least once a week to get the EPG data. I guess the EPG data collecting stops within the first 24h after backend has been started. I live in Finland, just like the person who created this ticket.

I've been using mythtv from 0.21_beta16340 to 0.22_p23069 and this problem has always been present. My workaround has been a cronjob to restart mythbackend every now and then.

Samppa

Same problem here as well. I started from 0.20 and still same problem with 0.22 (lastes official ubuntu 9.10-version, sorry can't remember correct number). It seems thta EIT works only one week roughly and then stop. Restarting backend fix this issue for next week. I am living in Tampere/Finland? using TTV-cable.

br, Tomi

I've been using Myth with DVB-T in Finland >4 years and never had this kind of problems. Could it be DVB-C related, or related to particular card?

Might be, I never had this problem with 0.18 and 0.19 but problem start with 0.20. Also my friend have same issue, we both have cable-card, Technotrend c1500 and both using TTV-cable. We both using ubuntu, different verison. I have tried ubuntu 8.04, 8.10, 9.04 and 9.10 without success.

I just checked my myth version and it is 0.22-fixes (22594)

br, Tomi

One more idea, we both have 2 cards, both are technotrend c1500 budget. in backend setup you could select how to use cards to get EIT data but even I change those I don't see any difference. Could this help somebody who know how this is coded?

Br, Tomi

comment:30 in reply to: ↑ 29 Changed 8 years ago by anonymous

Replying to anonymous:

Replying to TomiL:

Might be, I never had this problem with 0.18 and 0.19 but problem start with 0.20. Also my friend have same issue, we both have cable-card, Technotrend c1500 and both using TTV-cable. We both using ubuntu, different verison. I have tried ubuntu 8.04, 8.10, 9.04 and 9.10 without success.

I just checked my myth version and it is 0.22-fixes (22594)

br, Tomi

One more idea, we both have 2 cards, both are technotrend c1500 budget. in backend setup you could select how to use cards to get EIT data but even I change those I don't see any difference. Could this help somebody who know how this is coded?

I have two Terratec Cinergy 1200 MK3 DVB-C cards, Gentoo linux, my cable provider is KYMP.

Samppa

comment:31 follow-up: Changed 8 years ago by Markus Schulz <msc@…>

looks like the problem has nothing to do with the type of the dvb card, i have it with dvb-c and dvb-s.

every time the scanner stops on one card the last log message was: 2010-03-30 22:34:25.878 DVBChan(11:/dev/dvb/adapter3/frontend0) Error: SetChannelByString?(139): Multiplex is not available 2010-03-30 22:34:25.878 TVRec(11) Error: Failed to set channel to 139. Reverting to kState_None 2010-03-30 22:34:26.255 EITScanner (11): Now looking for EIT data on multiplex of channel 139

and with a recording on this card the scanner reappears: 2010-04-02 11:43:51.229 TVRec(11): Changing from None to RecordingOnly? 2010-04-02 11:43:51.235 TVRec(11): HW Tuner: 11->11 2010-04-02 11:43:51.816 Started recording: TEstaufnahme "Fri Apr 2 11:43:00 2010": channel 31106 on cardid 11, sourceid 3 2010-04-02 11:43:52.725 EITScanner (11): Started passive scan. 2010-04-02 11:43:52.728 TVRec(11): rec->GetFileName?(): '/data/tv-rec/31106_20100402114400.mpg' ... 2010-04-02 11:56:01.645 EITScanner (11): Now looking for EIT data on multiplex of channel 84

comment:32 in reply to: ↑ 31 Changed 8 years ago by janne

  • Version changed from 0.21-fixes to head

Replying to Markus Schulz <msc@…>:

looks like the problem has nothing to do with the type of the dvb card, i have it with dvb-c and dvb-s.

every time the scanner stops on one card the last log message was: 2010-03-30 22:34:25.878 DVBChan(11:/dev/dvb/adapter3/frontend0) Error: SetChannelByString?(139): Multiplex is not available 2010-03-30 22:34:25.878 TVRec(11) Error: Failed to set channel to 139. Reverting to kState_None 2010-03-30 22:34:26.255 EITScanner (11): Now looking for EIT data on multiplex of channel 139

I thought I fixed that failure already.

comment:33 follow-up: Changed 8 years ago by stuarta

It's possible that the version data on the EIT info isn't changing, thus the eitcache won't let the update through as it already has it.

Stuart

comment:34 in reply to: ↑ 33 Changed 8 years ago by Markus Schulz <msc@…>

Replying to stuarta:

It's possible that the version data on the EIT info isn't changing, thus the eitcache won't let the update through as it already has it.

No, i don't think so. The tuning to the channel (SetChannelByString?(..)) has no success and the eit-scanner seems to wait endless for data.

In some cases, i know why the tuning has no success, cause the channel is not available all the time. A good solution was to tune to the multiplex instead to a particular channel, but thats a major update (but a good start to refactor many device-dependent stuff out from tv_rec.cpp).

But some of the SetChannelByString?(..) errors comes from channels which broadcasts all the time, so it must be another problem with same result (scanner waits endless for data but tuning hasn't success).

comment:35 Changed 8 years ago by stuarta

After re-reading the code i was talking rubbish, it's got nothing to do with the eitcache. We probably need to have a look and see if the eit scanner handles when the channel tune fails or not, perhaps it should skip onto the next channel in this case.

Stuart

comment:36 Changed 8 years ago by stuarta

  • Milestone changed from 0.23 to 0.23-fixes

comment:37 Changed 8 years ago by robertm

  • Milestone changed from 0.23-fixes to 0.24

comment:38 Changed 8 years ago by robertm

  • Owner changed from janne to janneg
  • Status changed from new to assigned

comment:39 Changed 8 years ago by robertm

  • Owner changed from janneg to janne

comment:40 Changed 7 years ago by stuartm

  • Milestone changed from 0.24 to 0.24.1

comment:41 Changed 7 years ago by timowi <mythtv@…>

I had the same problem at least with 0.22. I am not sure if the problem still exists as I still restart the backend twice a week. I can check this with 0.24-fixes.

I have two DVB-S cards (TechnoTrend? S-2400) five recorders each. I tried to track the problem with 0.22 and noticed that the scanner stopped during recordings.

comment:42 Changed 7 years ago by ailincai2000@…

The same problem here, eit stop collecting data on LIVE TV or recording. If i start backend and let it idle, eit is working, when i start live tv or scheduled recording, eit stops. I use mythbuntu 11.04 and myth 0.24.1 28/05/2011 version.

comment:43 Changed 7 years ago by stuartm

  • Milestone changed from 0.24.1 to 0.24.2

comment:44 Changed 6 years ago by danielk

  • Resolution set to Fixed
  • Status changed from assigned to closed

It appears janne's fix for the initially reported problem was applied to at some point. Please open a new ticket for any other issues, even if they have similar symptoms.

comment:45 Changed 6 years ago by mythtv@…

Should I open a new ticket although the initial problem I reported 3 years ago still is there?

comment:46 Changed 6 years ago by danielk

  • Ticket locked set

comment:47 Changed 6 years ago by stuartm

  • Milestone 0.24.2 deleted

Milestone 0.24.2 deleted

Add Comment

Modify Ticket

Action
as closed The owner will remain janne.
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.