Opened 14 years ago

Closed 13 years ago

#3489 closed defect (fixed)

IPTV URLFetcher::FetchData appears to "lockup" sporadically

Reported by: greg Owned by: danielk
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no


It appears that there is something going on when starting an IPTV recording which can cause the qApp->processEvents() call in URLFetcher::FetchData? to never return and ends up leaving the backend process in a statewhere all network/mythsocket activity just stops. I can see from the logs that the JobQueue? is still running but no new connections can start and existing ones basically die until mythbackend is restarted.

It doesn't happen everytime a recording starts, but does seem to be more likely to occur if I'm in the middle of streaming a show from that backend to a frontend already. Be it LiveTV or a recording.

My M3U file is local to the backend and I've used both "/home/mythtv/.mythtv/iptv.m3u" and "file:///home/mythtv/.mythtv/iptv.m3u" with the same results each time.

If there is anything else I can provide or try just let me know. I will be testing with a newer version of QT just in case that is the cause of my problem.

Current versions :

QT - 3.3.3 Mythtv - SVN-Head- 13482

Attachments (2)

gdb.txt (38.8 KB) - added by greg 14 years ago.
iptv-fix.diff (487 bytes) - added by greg 14 years ago.
Simple patch to avoid recalling FetchData?

Download all attachments as: .zip

Change History (9)

comment:1 Changed 14 years ago by greg

Just wanted to add some more notes on this. This problem only occurs AFTER an iptvrecording finishes.

So I can start as many recordings as I like,but after 1 finishes, the very next one to start will hang at the qApp->processEvents() call and all future recordings fail and all current mythsocket transactions grind to a halt until the backend is restarted.

I've updated my QT to 3.3.8 so at this point I'm thinking that something isn;t being torn down correctly when a recording finishes and a thread is left hanging.

I've attached a backtrace from after the system has gotten into this state if it's of any use.

Changed 14 years ago by greg

Attachment: gdb.txt added

comment:2 Changed 14 years ago by koying

Same here. On my side, it happens systematically when doing back-to-back recordings. (QT 3.3.8 - SVN 13775)

comment:3 Changed 14 years ago by danielk

Owner: changed from Isaac Richards to danielk

comment:4 Changed 14 years ago by greg

Just an update on this one. I've "gotten around" the problem but certainly not fixed it with the attached patch. Basically I just avoid clearing the list of channels so we never end up calling FetchData? again so it never stalls.

Changed 14 years ago by greg

Attachment: iptv-fix.diff added

Simple patch to avoid recalling FetchData?

comment:5 Changed 13 years ago by anonymous

FWIW, While I was having exactly this same problem, and applying that patch has resolved it, I am getting a different symptom now (for several weeks) - after some amount of running one or more of the defined IPTV recorders will cease to work properly. It still "thinks" it has made a recording, and the entry appears in 'recordings', but upon selecting it it informs that the file cannot be found. If LiveTV happens to pick the tuner it tries for a moment and then reports unable to lock...

Shutting down and restarting the backend clears the problem, at least until it recurs

I'm not quite sure how to troubleshoot this.

comment:6 Changed 13 years ago by megadave@…

Er, bah. Previous comment is mine. Forgot to enter my email.

comment:7 Changed 13 years ago by greg

Resolution: fixed
Status: newclosed

(In [16024])

Closes #3489. This patch avoids clearing the channel list everytime so we don't need reloading it

Note: See TracTickets for help on using tickets.