Opened 8 years ago

Closed 7 years ago

#10493 closed Bug Report - Hang/Deadlock (Fixed)

Mythbackend 0.25 keeps tuners/recordings going after quit

Reported by: mythtvuser@… Owned by:
Priority: minor Milestone: 0.27
Component: MythTV - General Version: Master Head
Severity: low Keywords:
Cc: Ticket locked: no

Description

I updated my 0.24 pvr to 0.25 today and i found a nasty bug in 0.25 (mythtv-backend-0.25-280_v0.25_beta_55_g814e880.el6.x86_64)

Background : I use iptv (m3u file) and have around 7 tuners created ..6 for recordings and 1 for free livetv

After my upgrade the first time i went into livetv i had a black screen and after xxx seconds i was thrown back to the menu.. In the past this would happen and i got a error saying that he couldn't buffer etc. so i wasn't alarmed and just thought.. he beta.. this could be the same ignore it.. So pressed the livetv again and voila there the livetv was..

So i played a littlebit with the new setup.. went to the epg to see if the crash problem that i had was fixed.. and it looked like everything was ok there.. so i programmed some new recordings.. ans looked in the recordings and there they where.. so far so good i thought.. Nice update..;) I deleted the recordings(while they still where recording) because it was just testing..

But then it came.. I thought lets get back to livetv and for some reason i couldn't get in.. I thought that is strange.. So i looked around in log etc. and found out that for a strange reason all my tuners where still busy.. BUT mythbackend/frontend was saying they were free.. So i looked at my storage area to see what the last files where that were created.. maybe there was something there.. And there it was.. The last files where still growing.. and lsof was saying mythbackend was the one using it..

So i restarted the backend and confirmed that there were no files in use anymore.. and it wasn't.. So i started a livetv again and it was running great and the storage area file was created and growing... But when i stopped the livetv.. the file kept growing again.. So i started a livetv again.. and there it was a second file was created and that was growing also.. including the first one.. To be sure there were no recordings going on i check the fronted recording again.. and it wasn't..

So to test my theory i started livetv again to see if a 3th file would be created.. and yes it was and still the first 2 were growing larger and larger.. To test allitlebit more i started a recording from an epg and deleted it again.. mythtv/recording was empty but the file was there and growing.. So now i had 4 files growing and nothing was beeing used on the box..

I was curious and started livetv 3 times more.. and there it was 7 files growing.. info center saying tuners are free and everything else failing.. no more livetv possible etc..

To stop the process i restarted the backend again and all files were released again.

I did they above 3 times more and every time i had the same outcome..

Attachments (1)

mythbackend0.25.tar.bz2 (238.1 KB) - added by mythtvuser@… 8 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 8 years ago by mythtvuser@…

Because of this error i decided to downgrade to the stable version because this is my only mythtv box. If needed i can upgrade again.

comment:2 Changed 8 years ago by danielk

Milestone: 0.250.26
Priority: majorminor
Severity: highlow

The iptv support is pretty busted but this won't be fixed for 0.25. If you are interested there is an an rtp branch which is a total rewrite of the iptv support in MythTV. So far it only supports rtp and udp streams, but rtmp is coming soon.

comment:3 Changed 8 years ago by mythtvuser@…

Ok that explains. Going to have a look at that.. If interested for debugging i attach the log files from yesterday.. I will wait until 0.26. Thank you for the reply.

Changed 8 years ago by mythtvuser@…

Attachment: mythbackend0.25.tar.bz2 added

comment:4 Changed 8 years ago by chemobejk@…

The one real reason for me to upgrade to 0.25 turns out to be a bust :-(

As it doesn't work at all I decided to try a backport. By looking at the devel/rtp branch I determined that between those commits are the real changes in that branch:

# devel/rtp branch-off from master
$ git log -n1 --oneline b758ea8
b758ea8 Alter the watched flag fix slightly ....
# devel/rtp last real change
$ git log -n1 --oneline 164b130
164b130 Whitespace fixes.

From that information I derived the differences between 0.25 and devel-rtp with

$ git log --reverse --oneline v0.25..164b130 | fgrep -v "Merge branch" | tee cherry-pick-list.txt
715c18c Remove old iptv recorder and replace with stubs for new iptv recorder without the Live555 baggage.
02768bd Add IPTVStreamHandler.
5eeee9c Adds RTPDataPacket/RTPFECPacket/RTPTSPacket stubs.
e124592 Rework IPTV MPEGStreamData handling a bit so that it can work for the signal monitor too.
1e7606d Fixes a few RTP bugs preventing data from getting to the MPEGStreamData::ProcessData() function.
cfe2a50 Formatting fixes.
3b3b172 Adds Raw UDP streaming support.
64008d6 Increase the RCVBUF size for RTP/UDP sockets and set the broadcast flags so we can see broadcast streams.
ca36ff0 Set some sane settings for UDP sockets in IPTVStreamHandler.
f3e37ed Add IPTV Channel URLs to DB.
ed6ebe1 Change SignalMonitor shutdown so it works for IPTVSignalMonitor
473c4ec Call Close() in IPTVRecorder dtor.
527c910 Set up IPTVStreamHandler only when we have a StreamData.
f160c64 Fix two transposition typos in FEC type parsing.
c2d535f Fix out-of-order RTP packet delivery.
1e97a18 Print warning when there is a break in the rtp sequence numbers.
fc54265 Implement RTPTSDataPacket::GetTSOffset()
42a9e13 added rtsp files
002ef26 rtsp streaming on iptv
8dd9532 parse logic for SETUP url fixed for rtsp streaming
3dbe393 RTP streaming bug fixed for FPE
164b130 Whitespace fixes.

Now I created a new branch of fixes/0.25 and cherry-picked the above list of 22 commits on top of that:

$ git branch --no-track fixes/0.25+rtp origin/fixes/0.25
$ git checkout fixes/0.25+rtp
$ git cherry-pick -x $(cut <cherry-pick-list.txt -d' ' -f1)

As it turned out only two of the commits required minor conflict resolving. I also noticed that master had already a DB schema update done in 0fcf963, so I backported that one too, so that the DB schema update of fixes/0.25+rtp will end up at the same version 1301.

Then I replaced mythtv-0.25-fixes.patch in the SRPM with the full patch from fixes/0.25+rtp, fired off the build and crossed my fingers. The compilation went through fine. I replaced my old installation, fired up mythtv-setup to create a new IPTV recorder. After starting mythbackend I was able to watch IPTV and the backend no longer gets stuck at the end of the recording. Looks promising...

I'll have to see how multiple IPTV recordings will work out with the new code. That was the one thing that really didn't work reliably in 0.24.

If there is interest I could push the fixes/0.25+rtp branch to a public place.

comment:5 in reply to:  4 Changed 8 years ago by p.gomersbach@…

Replying to chemobejk@…:

The one real reason for me to upgrade to 0.25 turns out to be a bust :-(

As it doesn't work at all I decided to try a backport. By looking at the devel/rtp branch I determined that between those commits are the real changes in that branch:

# devel/rtp branch-off from master
$ git log -n1 --oneline b758ea8
b758ea8 Alter the watched flag fix slightly ....
# devel/rtp last real change
$ git log -n1 --oneline 164b130
164b130 Whitespace fixes.

From that information I derived the differences between 0.25 and devel-rtp with

$ git log --reverse --oneline v0.25..164b130 | fgrep -v "Merge branch" | tee cherry-pick-list.txt
715c18c Remove old iptv recorder and replace with stubs for new iptv recorder without the Live555 baggage.
02768bd Add IPTVStreamHandler.
5eeee9c Adds RTPDataPacket/RTPFECPacket/RTPTSPacket stubs.
e124592 Rework IPTV MPEGStreamData handling a bit so that it can work for the signal monitor too.
1e7606d Fixes a few RTP bugs preventing data from getting to the MPEGStreamData::ProcessData() function.
cfe2a50 Formatting fixes.
3b3b172 Adds Raw UDP streaming support.
64008d6 Increase the RCVBUF size for RTP/UDP sockets and set the broadcast flags so we can see broadcast streams.
ca36ff0 Set some sane settings for UDP sockets in IPTVStreamHandler.
f3e37ed Add IPTV Channel URLs to DB.
ed6ebe1 Change SignalMonitor shutdown so it works for IPTVSignalMonitor
473c4ec Call Close() in IPTVRecorder dtor.
527c910 Set up IPTVStreamHandler only when we have a StreamData.
f160c64 Fix two transposition typos in FEC type parsing.
c2d535f Fix out-of-order RTP packet delivery.
1e97a18 Print warning when there is a break in the rtp sequence numbers.
fc54265 Implement RTPTSDataPacket::GetTSOffset()
42a9e13 added rtsp files
002ef26 rtsp streaming on iptv
8dd9532 parse logic for SETUP url fixed for rtsp streaming
3dbe393 RTP streaming bug fixed for FPE
164b130 Whitespace fixes.

Now I created a new branch of fixes/0.25 and cherry-picked the above list of 22 commits on top of that:

$ git branch --no-track fixes/0.25+rtp origin/fixes/0.25
$ git checkout fixes/0.25+rtp
$ git cherry-pick -x $(cut <cherry-pick-list.txt -d' ' -f1)

As it turned out only two of the commits required minor conflict resolving. I also noticed that master had already a DB schema update done in 0fcf963, so I backported that one too, so that the DB schema update of fixes/0.25+rtp will end up at the same version 1301.

Then I replaced mythtv-0.25-fixes.patch in the SRPM with the full patch from fixes/0.25+rtp, fired off the build and crossed my fingers. The compilation went through fine. I replaced my old installation, fired up mythtv-setup to create a new IPTV recorder. After starting mythbackend I was able to watch IPTV and the backend no longer gets stuck at the end of the recording. Looks promising...

I'll have to see how multiple IPTV recordings will work out with the new code. That was the one thing that really didn't work reliably in 0.24.

If there is interest I could push the fixes/0.25+rtp branch to a public place.

Hi, I'm having the same problem so interested.

comment:6 Changed 8 years ago by iwelcomespam@…

I'm having the same problem and hit the same IPTV bug you're experiencing. so Yes very interested.

comment:7 Changed 8 years ago by chemobejk@…

I've pushed the branches fixes/0.25 and fixes/0.25+rtp into a git repo on my web server. You can clone it with:

$ git clone -b fixes/0.25+rtp http://chemobejk.dyndns.org/git/mythtv.git

As this is dumb HTTP you won't see any progress report, so please make sure to wait until the command completes.

comment:8 Changed 8 years ago by Aaron Yourk <ayourk@…>

How soon until this repository is up? Any chance you could post the patch file you created?

comment:9 Changed 8 years ago by chemobejk@…

The repository is already up since several days and I have rebased the branch while I'm tracking fixes/0.25. I've tried to clone it myself and it works, it just takes a while to download.

comment:10 Changed 8 years ago by Kenni Lund [kenni a kelu dot dk]

Ticket locked: set

Please continue this discussion on the mythtv-users mailing list.

comment:11 Changed 7 years ago by JYA

Ticket locked: unset

comment:12 Changed 7 years ago by JYA

Milestone: 0.260.27

Using vanilla fixes/0.25 Please try applying this commit: https://github.com/MythTV/mythtv/commit/d83672529ac1d851d67ca0c06b0b11b64e141119

and see if it works any better (it should)

comment:13 Changed 7 years ago by Michael@…

Hi

I just recompiled fixes/0.25 including this commit and it works for me. Running CentOS 6.2 64 bit newest updates.

I have 3 IPTV tuners and they are released after viewing live tv.

I can change program using the guide, but not by typing channel nr. It drops to main menu. (using 0.25 from atrpms on fedora frontend)

Even when not successfull in changing channel the backend remains responsive. scheduled recordings are starting shortly but I expect them to work as well.

From my point of view it is now useable.. :-)

-Michael

comment:14 Changed 7 years ago by chemobejk@…

I sincerely hope that the intention of this fix is to provide a solution for fixes/0.25 and not as a feature for 0.26 or 0.27. The new implementation in devel/rtp is superior to the Live555-based code in 0.25.

comment:15 Changed 7 years ago by JYA

Resolution: Fixed
Status: newclosed
Note: See TracTickets for help on using tickets.