RTSP Support Broken in Pre-0.25 Branch...

[raymondboettcher@…]

I've made tons of attempts to get this to work... I've tried VLC and then finally LIVE555 Media Server. I made 3 streams, 1 MPEG1 - MP2 Audio, 1 MPEG2 - MP2 Audio, and finally 1 MPEG2-TS - MP2 Audio stream using FFMPEG. I have done everything I can imagine to get this to work. However, the results do work great in VLC. LIVE555 Media Server even offers UDP and TCP RTSP as well as a RTSP over HTTP Server. There can't be any way that I've missed something here. Playlist File is as Follows:

#EXTM3U #EXTINF:0,1001 - DRI rtsp://192.168.100.99:554/Simpsons.mpg

I tune to channel 1001 and get "You should have received a channel lock by now. You can continue to wait for a signal or you can..."

I have attached a log with -v playback,record as the options. Hopefully this is good enough but if you need more, let me know. This log was generated while using LIVE555 Streaming Server as the Server which VLC streams from with no problems. They do have a prebuilt binary version (which I used) at:

​http://www.live555.com/mediaServer/#downloading

I tried specifying a file that doesn't exist on the RTSP Server and it does complain about that without any verbose logging. However, without verbose logging and the stream does exist, you'd never know there was a problem without the verbose logging (Well except the fact that video never plays).

Note: Usage of the Server is SIMPLE, download the binary to a folder. Then drop your MPEG video files in the folder with it. Run the server from inside that folder and it will offer the video files that are in the folder automatically. It will use the default RTSP port 554 on both UDP and TCP and VLC will smile when you access them. I can even seek around the stream, which I wasn't expecting.

[raymondboettcher@…]

Mythbackend log with -v playback,record.

[raymondboettcher@…]

The #EXTE3U is on it's own line... I don't understand when I copy and paste things it wraps it all on 1 line.

[raymondboettcher@…]

Playlist.m3u offered to Network Tuner.

[raymondboettcher@…]

Ohh, and I did try the DEMO/MPEG Tuner and was able to play the MPEG file directly at that point. I even pulled up the program guide, etc while the video was playing.

[raymondboettcher@…]

MythTV Version : v0.25pre-1429-ge291378

[raymondboettcher@…]

Slackware 13.1 with MythTV 0.24 Release seems to have the same problem, however the handling is better and doesn't hang the "Network Tuner" causing me to restart the backend in order to try again. I'm attaching that log file now with the same parms -v record,playback...

[raymondboettcher@…]

Fresh Install Slackware 13.1 with MythTV Official 0.24...

[raymondboettcher@…]

RTSP and UDP Protocols are tested and working in MythTV 0.23.1... My third stream (MPEGTS) seems to be the only one that works correctly. I never get a LAM Lock with the others. But the interface doesn't hang and the Network Tuner works as expected. Mythbackend doesn't cause any of the dead locks that are experienced with the Pre-0.25 Branch which is likely the cause for the interface hang...

[danielk]

Please test with the mythtv-rec2 branch, if the same problem appears there I'll try to reproduce it and fix it.

[raymondboettcher@…]

Okay... So heres the story on that.. It automatically tunes to Channel 1001 which is a UDP:// URL Feed. I switched channels to 1004 which is the rtsp:// feed and get some interesting results but no RTSP Feed Playback. Same playlist.m3u file. I'm going to attach that log now.

[raymondboettcher@…]

Mythbackend Rec2-Pre-0.25

[raymondboettcher@…]

If I move the RTSP Feed to the default channel 1001. It says "Please Wait..." when entering "Watch TV" and then it eventually times out and drops back to the "TV" Menu. I just tested this...

[raymondboettcher@…]

Version: mythtv-v0.25pre-1524-gc611adb

[raymondboettcher@…]

udp:// feeds don't appear to be working either, fyi...

[raymondboettcher@…]

Works better in mythtv-80192ec (MythTV 0.24+fixes Branch) than it did in 0.23.1.. Upgrading my primary system now. Even closes UDP sockets when it's done which was a problem in 0.23.1 on stream timeout which causes the feed to run forever. Knowing this will allow me to patch my MythIPTVStreamer accordingly to watch for the 0.23.1 bug... I had an error with the "Jump to list" as I was entering LiveTV one time but since I left the house and came back it seems to have expired or deleted whatever was causing the problem and its working again. Might have been a strange fluke, I will test that problem later. So that I don't put you out of your way, I'm going to kick off another fresh Slackware 13.1 in my VirtualBox? VM and install rec2 fresh. I did a make uninstall on Pre-0.25 last time and and installed rec2 and used the same schema from the master branch. I want to absolutely ensure this is rec2 specific. Getting 0.24+fixes working gave me hope... Last time I used 0.24 as offered from the website. Now that I'm starting to understand the DB Scema and what MythTV expects from the stream itself, I have a much better understanding and can assist much better.

[raymondboettcher@…]

I'll post again on this ticket when I've tried this again in a absolutely clean environment. When this is said and done, I'm going to release the first beta to MythIPTVStreamer under GPL which supports HTTP, RTP, MMSH, MMST, RTSP, UDP, Shoutcast ICY Servers, and Flash Video Streams in a large variety of codecs. The purpose of the program is to transcode the stream to MPEG2, MP2 Audio and stick it into a MPEGTS Container for streaming to Mythbackend via UDP:// protocol. Until the protocol list is expanded in the Network Tuner, this will offer a viable workaround to bring 99% of all streaming television into the MythTV System. The program supports the "bypassfeeder" option for those streams types and codecs that are directly supported by MythTV since the program self-generates the M3U File that MythTV reads. I already have a working configuration with 4 (MMSH) UK Channels, and 6 Shoutcast (HTTP) ICY Servers for MythTV 0.23.1.

[raymondboettcher@…]

Ugh, thats a first... MythTV 0.24+Fixes: sh: line 1: 21656 Aborted /usr/bin/mythpreviewgen --size 0x0 --chanid 2001 --starttime 20110401225423 > /dev/null 2011-04-01 22:55:15.998 Preview Error: Encountered problems running '/usr/bin/mythpreviewgen --size 0x0 --chanid 2001 --starttime 20110401225423 > /dev/null'

[raymondboettcher@…]

Error opening jump program file buffer issue found. (Ticket Reference #9034).

[raymondboettcher@…]

MythTV Master (v0.25pre-1623-ge682122). There is definitely a mutex lock scenario going on causing a hang in mythbackend... The problem is causing mythbackend to become unresponsive to the frontend. It ends poorly with the frontend dropping out (after a minute or so) of Live TV saying that there is "no tuners free for live tv".

[raymondboettcher@…]

RTSP and UDP don't work in MythTV rec2 branch (mythtv-v0.25pre-1524-gc611adb)... Getting playback is still impossible but at least it doesn't deadlock. Instead it seems to refuse opening the ringbuffer file because its 0 bytes. I get a LAM Lock but no feed and an error about opening the RingBuffer?? file. Network Tuner isn't directing the stream to the ringbuffer perhaps? It also complains "SendMythSystemPlayEvent??() called with empty ProgramInfo??" but technically there is no program info because I have the IPTV Tuner assigned to no grabber. I'm not sure why that would throw an error, perhaps pass it "Unknown" as the program name? MythTV 0.23.1 seems to do that.

[raymondboettcher@…]

Setting Channel through schedule recordings ends with continuous loop causing 100's of entries under "Watch Recordings" to appear and complains about some files not existing. Anyhow, I'll leave Myth-rec2 installed on my VM for now. Just let me know any further information you may need.

[raymondboettcher@…]

Adding Guide information didn't improve the situation.

[danielk]

Does it work with the latest master?

[raymondboettcher@…]

I wish I got an e-mail when this updates... Give me a day or so, I'll compile the latest master and let you know.

[raymondboettcher@…]

Okay going in order of release. Now tested on 0.24.1 as seen on the website for download.

[raymondboettcher@…]

This version seems to work better. It seems to wait for a feed now instead of giving up. It does display a "No Signal" dialog after a short period of time but if I manually fire a feed at the Network Tuner it goes away and the feed begins. But if for some reason the feed pauses or gets interupted for a short period of time after the Tuner has started to view the feed then it will drop out of "Live TV" with "Video frame buffering failed too many times." Perhaps signal should return to "Partial-Lock" and reset back to the waiting state again and trust the fact that the backend isn't messing up. :) Easily achieved if you send a custom MPEG-TS No-Op Packet that won't be recorded to the drive but inform the frontend that the backend is waiting for more information. The packet would also reset the timeout timer. I only had the socket stay open once and for some reason can't re-replicate the result. Results so far are promising... But this is 0.24.1, so, I'm moving forward to the newest GIT Version.

[raymondboettcher@…]

0.24.1 also sticks at the "Please Wait..." screen once in a while when entering Live TV and the Network Tuner is the only Capture Device. I haven't really figured out a pattern yet to what makes it happen as it does it sometimes and not others. I'm not going to research further with 0.24.1 though, but I will nail it down if I find the problem in latest GIT.

[raymondboettcher@…]

Not testing scheduled recordings, etc in 0.24.1 and going directly to latest GIT... I will post here again when I get that system live.

[raymondboettcher@…]

Oh wait, just as I was getting ready to kill everything, I left it in Live TV for a few minutes and got "Error opening jump program file buffer" and now the socket is still open! Okay, moving forward...

[raymondboettcher@…]

INSTALLER SCRIPT NOTES: "make uninstall" removes *MY* compiled copy of ffmpeg (executables and all) and also leaves /usr/include/mythtv behind with with files and subfolders. This has been true for quite a few versions, I just forgot to say something about it. I left my ffmpeg source in my home directory so I can go right back into that directory and run "make install" again after removing MythTV. Don't worrie, I have been deleting the include folder before installing a new version each time. But the directories in /usr/include/mythtv also looks ffmpeg related. I've been installing ffmpeg first before MythTV. I'll create a ticket if needed...

[raymondboettcher@…]

Commit: ge433387
mythbackend crashes in relation to qt issue on startup...

Commit: gf659892
mythtv-setup doesn't create the database correctly. Attaching Log...
I will wait a few days on this and download another commit.

[raymondboettcher@…]

Initial Database Setup Problem.

[raymondboettcher@…]

Untestable until DB Schema problem is resolved, pushing back to assigned pool.

[raymondboettcher@…]

Dump of Schema created by failed myth-setup. (Schema was initially empty).

[robertm]

Raymond, STOP updating your ticket. You've made this ticket virtually unaddressable by filling it with irrelevant garbage. It is still infoneeded. Do not update this ticket until you are ACTUALLY able to address the question asked of you. When you do, update it ONCE and then STOP.

[raymondboettcher@…]

Okay, 1 update got it. Sorry, I tend to find out other stuff and update again and again, moving on.

Version Code: v0.25pre-3071-gfcb124d

Short Version: The Network Tuner works better but still doesn't work correctly in the New Master...

Long Version: The Network Tuner works better and the first attempt seems to pickup a feed. However, exiting and returning to Live TV causes the IPTV Tuner to become forever "Busy". Also, changing IPTV Channels causes Live TV to end (no error mentioned) and re-entry also returns "All Tuners Busy" (There is currently only 1 tuner configured (Network Tuner)). Only restarting the backend fixes this problem. Status from the Frontend says that "Tuner 1 is not recording." and the UDP Socket is still open but mythbackend ignores it (Tuner Cleanup Problem?).

Mythbackend is also trying to "INSERT" a record into the database about the current Live TV Feed, it fails due to an attempt to INSERT a NULL into the "recorded->category" database field that is flagged not to accept NULL's. The channel currently doesn't have any Guide Information and is configured as "No Grabber."

[raymondboettcher@…]

SQL Insert Error on Live TV Start.

[raymondboettcher@…]

New MythBackend? Log...

[raymondboettcher@…]

Forgot to toss back into 'assigned queue', sorry, if you need more information, just let me know.

[jm.detrez@…]

• Exactly same here with mythfrontend version: master [v0.25pre-3262-gabc4911].
• After you stop the tv playback, tuner is not released and the file in the livetv folder keep growing since the backend isn't restart.

Adding grabber on the source avoid SQL error but didn't solve the issue. Ask if you need more info, Jean-MArc.

[danielk]

We're not getting past the signal monitor because we're looking for a TS stream but seeing a PS stream.

[danielk]

It appears that we don't actually support PS streams at all in the IPTV recorder and that is not a regression in trunk. With TS streams we do get hung up sometimes inside the libmythlive555 library.

#0  0x00007f07f82bfff3 in select () from /lib/libc.so.6
#1  0x00007f07fe09e3a2 in blockUntilReadable (env=..., socket=49, buffer=0x1012c9170 "\200 \313\367\241\252\341\033c\340Fu", 
    bufferSize=9984, fromAddress=..., timeout=0x0) at groupsock/GroupsockHelper.cpp:219
#2  readSocket (env=..., socket=49, buffer=0x1012c9170 "\200 \313\367\241\252\341\033c\340Fu", bufferSize=9984, fromAddress=..., 
    timeout=0x0) at groupsock/GroupsockHelper.cpp:250
#3  0x00007f07fe09c439 in Groupsock::handleRead (this=0x17a48f0, buffer=0x1012c9170 "\200 \313\367\241\252\341\033c\340Fu", 
    bufferMaxSize=<value optimized out>, bytesRead=@0x7f07e1bb387c, fromAddress=...) at groupsock/Groupsock.cpp:305
#4  0x00007f07fe0d72ca in RTPInterface::handleRead (this=0x18cab90, buffer=0x1012c9170 "\200 \313\367\241\252\341\033c\340Fu", 
    bufferMaxSize=0, bytesRead=@0x7f07e1bb387c, fromAddress=...) at liveMedia/RTPInterface.cpp:187
#5  0x00007f07fe0c92b0 in BufferedPacket::fillInData (this=0x1012c9100, rtpInterface=...) at liveMedia/MultiFramedRTPSource.cpp:338
#6  0x00007f07fe0c9739 in MultiFramedRTPSource::networkReadHandler (source=0x18cab00) at liveMedia/MultiFramedRTPSource.cpp:213
#7  0x00007f07fe09a869 in BasicTaskScheduler::SingleStep (this=0x17a49c0, maxDelayTime=500000)
    at BasicUsageEnvironment/BasicTaskScheduler.cpp:135
#8  0x00007f08016162ef in TimeoutedTaskScheduler::doEventLoop (this=0x17a49c0, watchVariable=0x17876f0 "")
    at iptv/timeoutedtaskscheduler.cpp:20
#9  0x00007f08016127fa in IPTVFeederLive::Run (this=0x17876c0) at iptv/iptvfeederlive.cpp:74
#10 0x00007f080160721e in IPTVFeederWrapper::Run (this=0x178bbb0) at iptv/iptvfeederwrapper.cpp:137
#11 0x00007f08015fc6c3 in IPTVRecorder::run (this=0x180d9e0) at iptvrecorder.cpp:133
#12 0x00007f07ff429e47 in MThread::run (this=0x7f07e80158f0) at mthread.cpp:307
#13 0x00007f07f8d8b775 in ?? () from /usr/lib/libQtCore.so.4
#14 0x00007f07faaab893 in ?? () from /usr/lib/libGL.so.1
#15 0x00007f07faf909ca in start_thread () from /lib/libpthread.so.0
#16 0x00007f07f82c770d in clone () from /lib/libc.so.6
#17 0x0000000000000000 in ?? ()

Unfortunately, the live555 maintainer makes syncing to a newer version of that library impossible and I have no interest in forking live555, so the fix for this will have to wait until we get rid of the live555 dependence entirely.

[danielk]

Patch to detect TS streams and disable TS portion of signal monitoring when the stream is not a transport stream.

[iwelcomespam@…]

I'm using IPTV tuners which worked great in 0.23/fixes. 0.24.2/fixes also work well with the IPTV tuner. However when I tried out the 0.25/fixes release IPTV will only play but once I try to change channels the FE gets stuck and returns with the "irrecoverable error". Trying to launch 'Watch TV' again shows that the BE is unavailable. In fact any connection either mythjobqueue, mythavutil, etc.. all get the same connection error. The BE seems stuck when a channel change on an IPTV stream is requested. My IPTV M3U looks like:

#EXTM3U #EXTINF:0,1 - LOOR001 udp://225.1.100.1:2001 #EXTINF:0,2 - WGNAMER udp://225.1.100.2:2001 #EXTINF:0,3 - KCRA udp://225.1.100.3:2001

I've also logged a bug that may be related to yours:

​http://code.mythtv.org/trac/ticket/10574

[danielk]

Raymond can you test master? The IPTV stuff should be working a fair bit better in master...

[pverha10@…]

I've tested the master (53b89ce) with slackware-14.0rc3. IPTV in this version gives me less problems than version 0.25.2, but it still doesn't keep running.

When I start live tv and press pause, I see the file grow up until an uncertain point (about 1 minute) after which it stops growing, so it seems to me that the backend stops writing data somehow. mythbackend only stops the recording when mythfrontend stops watching.

I can switch channels now though.

[danielk]

The live555 code is completely removed in master.