Originally Posted by Jim McCauley
Thanks for the reply!
What sort of DLNA PVR are you using?
I do it in two different parts. The recording is done by homegrown software that is HDHomeRun specific. The output would be the same as what the HDHomeRun linux command line tools would record. The HDHomeRun firmware does the subchannel filtering, reconstructing the PAT and making other adjustments to produce an mpeg transport stream file. So once I've configured the HDHomeRun for the program I want it is just a matter of receiving the stream from the HDHomeRun and writing it to a file.
I use minidlna as my DLNA server. The DLNA standard is partly based on uPNP. There are a lot of servers out there that claim to conform to the DLNA standard, but really only conform to uPNP. It turns out that my Sony TV is really picky about conformance to the DLNA standard, and minidlna was one of the few true DLNA servers that worked with my Sony TV. I thought I remembered Samsung TV's being less picky, but I just noticed some reviews on the minidlna SourceForge site that claimed that minidlna was the only DLNA server that worked without issues with their Samsung TV. I don't know how reliable those reviews are, but perhaps you should give minidlna a try (I don't know if you can have both MythTV and minidlna running at the same time, and since you'll want to continue to use MythTV for your recording you may need to configure MythTV to turn off DLNA/uPNP).
Originally Posted by Jim McCauley
Hm. My MythTV recording profiles for both commercial and PBS stations are identical. So the question remains: why can I skip on recordings from KRMA and KBDI but not on any
of the commercial channels?
When you asked what I used I remembered an issue that I ran into that led to the same problem, but it was a lot more random (although it happened much more frequently on KDVR than any other station). The issue is related to the wrapping of the mpeg PTS (Presentation Time Stamp). For mpeg program stream files, the PTS typically starts at 0 and counts up. For a transport/broadcast stream the PTS is continually running, and has to be reset at least once a day. A transport stream file is just a portion of that broadcast stream, so it may or may not contain a change in the PTS. Some stations reset the PTS only once or twice a day, whereas KDVR does it many times per day. I don't recall any other station doing it that often, but I don't have current data.
Anyway, if you record a program, and the station resets the PTS during that program, you will have a transport stream file whose start time is greater than the end time. There is nothing wrong with that as far as the standard goes, but the ffpmeg libavformat library didn't support that two years ago when I discovered the problem. Almost all open source media software uses the ffpmeg libraries, e.g. vlc, MythTV, minidlna, etc.
I reported the problem about two years ago, along with a patch. They followed up within a month and fixed the problem in the top of tree. Note that although the problem was fixed almost two years ago in the top of tree source, it sometimes can take a while to trickle down, i.e. make it into an official ffmpeg release, then make it into various media software releases, then have that incorporated into various linux distributions (depending on how the linux distribution is done the intermediate step may not be a factor). So if this problem is affecting you it may be fixed by a later release of MythTV if you are not running a recent version.
One way of verifying that this is the issue is via the ffmpeg command line tool. It's possible that you only have the libraries installed (i.e. libavformat, libavcodec, etc.). If so, you should be able install the ffmpeg command line tool. Then just type "ffmpeg -i ". The ffmpeg tool has various uses, but if you only specify an input file, ffmpeg will just print information related to the format of the file. It may also print a variety of errors that are not really an issue. Look for a line that shows the duration of the file. If it shows "Duration: N/A" then that would indicate you are running into this problem.
It appears that fffmpeg changed their tracking system and no longer shows the older issues, so I can't check which version of libavformat the fix was first incorporated into.