Kodi Community Forum

Can anyone confirm the compatibility of MythTV PVR Client 1.9.16 with MythTV backend 0.27.1? Mythbuntu 14.04 proposes me to upgrade the MythTV backend to 0.27.1, but I'm not sure if it is safe to do it as I didn't found any word on compatibility. Compatibility with 0.27 is declared clearly.

Yep it works with 27.1, I've been using it for a while.

There should never a protocol or database change within a mythtv release (eg from 0.27 to 0.27.1 or 0.27.2).

(Having said that there was an error once where this did eventuate but it was a mistake that I am sure the devs have learned from).

Thank you both!

Today I upgraded mythtv 0.27.1 to 0.27.2 using the mythbuntu 0.27 ppa:
2014-06-30 10:36:09 upgrade mythtv-backend:amd64 2:0.27.1+fixes.20140618.aa822f5-0ubuntu0mythbuntu2 2:0.27.2+fixes.20140630.54b3818-0ubuntu0mythbuntu2

Since then trying to watch live tv from xbmc 13.1 crashes mythtv-backend. I tried running xbmc both on the local box as well as from another xbmc installation on the network.

My installed versions of the relevant xbmc packages are:
xbmc-bin:amd64 2:13.1~git20140606.0917-gotham-0saucy
xbmc-pvr-mythtv-cmyth:amd64 1.9.16-16saucy

I will post a log of mythtv-backend when I find something useful. I don't see anything useful in xbmc.log:

21:41:40 T:140026614208256 NOTICE: PVRManager - starting up
21:41:40 T:140026402830080 NOTICE: Thread LanguageInvoker start, auto delete: false
21:41:40 T:140026394437376 NOTICE: Previous line repeats 1 times.
21:41:40 T:140026394437376 NOTICE: Thread PVRManager start, auto delete: false
21:41:40 T:140026386044672 NOTICE: Thread PVRClient start, auto delete: false
21:41:40 T:140026622600960 NOTICE: -->Python Interpreter Initialized<--
21:41:40 T:140026639386368 NOTICE: -->Python Interpreter Initialized<--
21:41:40 T:140027454756800 NOTICE: starting zeroconf publishing
21:41:40 T:140027454756800 NOTICE: ES: Starting event server
21:41:40 T:140025849173760 NOTICE: Thread JobWorker start, auto delete: true
21:41:40 T:140025832388352 NOTICE: Thread TCPServer start, auto delete: false
21:41:40 T:140025840781056 NOTICE: Thread EventServer start, auto delete: false
21:41:40 T:140025840781056 NOTICE: ES: Starting UDP Event server on 0.0.0.0:9777
21:41:40 T:140025840781056 NOTICE: UDP: Listening on port 9777
21:41:40 T:140026991261440 NOTICE: Thread RSSReader start, auto delete: false
21:41:40 T:140025823733504 NOTICE: Thread JobWorker start, auto delete: true
21:41:40 T:140026402830080 NOTICE: -->Python Interpreter Initialized<--
21:41:40 T:140026639386368 NOTICE: service.libraryautoupdate-0.9.4 : Update Library Service starting...
21:41:40 T:140026639386368 NOTICE: service.libraryautoupdate-0.9.4 : update timers
21:41:40 T:140026639386368 NOTICE: service.libraryautoupdate-0.9.4 : Creating timer for Video Library
21:41:40 T:140026630993664 NOTICE: -->Python Interpreter Initialized<--
21:41:40 T:140026402830080 NOTICE: StorageServer Module loaded RUN
21:41:40 T:140026402830080 NOTICE: StorageClient-2.5.4 Starting server
21:41:40 T:140026630993664 NOTICE: Thread AlarmClock start, auto delete: false
21:41:43 T:140027454756800 NOTICE: Storing total System Uptime
21:41:43 T:140027454756800 NOTICE: Saving settings
21:41:43 T:140027454756800 NOTICE: stop all
21:41:43 T:140027454756800 NOTICE: stop player
21:41:43 T:140027454756800 NOTICE: PVRManager - stopping

Similar problem here, with XBMC clients on Ubuntu 14.04, openelec 4.0.6, and windows 7. My backend doesn't crash every time, but it always fails to connect. My XBMC log file is here:

http://xbmclogs.com/show.php?id=238286

The attempt to watch live tv happened around 18:35:56. Here's a snippet from my mythbackend.log. Except for the last few lines, everything looks the same when connecting with mythfrontend (which works fine).

Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: I TVRecEvent tv_rec.cpp:1050 (
HandleStateChange) TVRec[12]: Changing from None to WatchingLiveTV
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: I TVRecEvent mythdbcon.cpp:409
(PurgeIdleConnections) New DB connection, total: 11
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: I TVRecEvent tv_rec.cpp:3603 (
TuningCheckForHWChange) TVRec[12]: HW Tuner: 12->12
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: N CoreContext autoexpire.cpp:2
64 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 3.0 GB w/freq: 14 min
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: I ProcessRequest mainserver.cp
p:1561 (HandleAnnounce) MainServer::HandleAnnounce FileTransfer
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: I ProcessRequest mainserver.cp
p:1563 (HandleAnnounce) adding: spica as a remote file transfer
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: E HDHRStreamHandler recorders/
dtvsignalmonitor.cpp:322 (HandlePAT) DTVSigMon[12](131C2E75-2): Program #0 not found in PAT
!#012Program Association Section#012 PSIP tableID(0x0) length(13) extension(0x20f)#012
version(17) current(1) section(0) last_section(0)#012 tsid(527) programCount(1)#012
program number 901 has PID 0x00a0
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: E HDHRStreamHandler recorders/
dtvsignalmonitor.cpp:328 (HandlePAT) DTVSigMon[12](131C2E75-2): But there is only one progr
am in the PAT, so we'll just use it
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: N HDHRStreamHandler recorders/
dtvsignalmonitor.cpp:367 (HandlePMT) DTVSigMon[12](131C2E75-2): PMT says program 901 is enc
rypted
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: E HDHRStreamHandler recorders/
hdhrstreamhandler.cpp:206 (UpdateFilters) HDHRSH(131C2E75-2): UpdateFilters called in wrong
tune mode
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: N CoreContext autoexpire.cpp:2
64 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 3.0 GB w/freq: 14 min
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: E TVRecEvent recordinginfo.cpp
:928 (InsertProgram) RecordingInfo::InsertProgram(ProgramInfo(3850_20140630223556.mpg): cha
nname(ESPNHD) startts(Mon Jun 30 22:00:00 2014) endts(Mon Jun 30 23:00:00 2014)#012
recstartts(Mon Jun 30 22:35:56 2014) recendts(Mon Jun 30 23:00:00 2014)#012
title(SportsCenter)): recording already exists...
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: E TVRecEvent recorders/recorde
rbase.cpp:206 (SetStrOption) RecBase[12](131C2E75-2): SetStrOption(...recordingtype): Optio
n not in profile.


Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: E ProcessRequest fileringbuffe
r.cpp:307 (OpenFile) FileRingBuf(/storage/sdc/livetv/3850_20140630223556.mpg): OpenFile():
File too small (0B).
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: E ProcessRequest mainserver.cp
p:1681 (HandleAnnounce) MainServer: Can't open /storage/sdc/livetv/3850_20140630223556.mpg
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: W MythSocketThread(77) mainser
ver.cpp:5971 (connectionClosed) MainServer: Unknown socket closing MythSocket(0x162da20)
Jun 30 18:35:56 media-server mythbackend: mythbackend[2223]: I TVRecEvent tv_rec.cpp:1050 (
HandleStateChange) TVRec[12]: Changing from WatchingLiveTV to None

I looked at the recordings directory, and there were two files - the one listed above, 3850_20140630223556.mpg, and one a second later - 3850_20140630223557.mpg. The first had zero bytes, the second 376.

I noticed that when watching with mythfrontend, the backend also sometimes creates two files and writes the video stream to the second, later file. This goes back to previous versions as I see the same pattern in livetv files from a month ago.

Put your logs on pastebin or similar please.

it's easy enough, ubuntu has a pastebin package.

Yes, I forgot to mention that mythtv frontend works fine.

Regarding the two files
-rw-r--r-- 1 mythtv mythtv 0 Jul 1 00:02 1001_20140630230258.mpg
-rw-r--r-- 1 mythtv mythtv 0 Jul 1 00:02 1001_20140630230259.mpg

Jul 1 00:02:59 club77 mythbackend: mythbackend[6225]: E ProcessRequest fileringbuffer.cpp:307 (OpenFile) FileRingBuf(/srv/data/mythtv/livetv/1001_20140630230258.mpg): OpenFile(): File too small (0B).
Jul 1 00:02:59 club77 mythbackend: mythbackend[6225]: E ProcessRequest mainserver.cpp:1681 (HandleAnnounce) MainServer: Can't open /srv/data/mythtv/livetv/1001_20140630230258.mpg
Jul 1 00:02:59 club77 mythbackend: mythbackend[6225]: W MythSocketThread(65) mainserver.cpp:5971 (connectionClosed) MainServer: Unknown socket closing MythSocket(0x2475dc0)

When I check mythbackend.log.1 I see that the "File too small (0B)" error happened previously too, but then it wasn't followed by the "Can't open ..." error. Normally it is followed by

Jun 1 22:04:02 club77 mythbackend: mythbackend[19628]: I ProcessRequest mainserver.cpp:1554 (HandleAnnounce) MainServer::HandleAnnounce FileTransfer

Not sure if that helps. I'll upload the logs tomorrow, it's getting late here.

I'm getting the same problem with 0.27.2. Downgraded to 0.27.1 and it worked. My mythtv backend log is attached here...

http://pastebin.com/sQyhUj9B

I forget about the time I downgraded, but I think you can see it at 20:17-ish. Everything before that was on 0.27.2.

same problem here as everyone else. central XBMC + mythtv Backend + 2 rpi openelec XBMC FEs. Everything working perfectly for months. Upgrade to 27.2 broke it. Everytime one of the rpi's tries to access mythtv, the mythtv-backend crashes.

I didn't collect logs, but if someone wants them I'll post them.

If anyone else wants to do what I did, which was rollback to the previous mythtv 27.1 packages I did it as follows:

If you then want to prevent being notified of available updates on the mythtv packages until this issue is resolved you can put a hold on each mythtv packages with:
or if you want to get fancy:

Hope that helps someone.

That was helpful, thanks tknorris.

i can reproduce xbmc not being able to connect.

mythbackend 0.27.2 now returns an error if a frontend is attempting to open a 0B recording.

the client is expected to check the return code when it tries to open a file, and if error to just go and use the next entry in the liveTV chain.

cmyth doesn't do that.
it doesn't check the return value and attempts to read regardless at which time the backend has dropped the connection.

i will revert the changes on the backend (dont particularly like doing so) so it doesn't return an error , but it's up to cmyth to properly do things.
and right now, it doesn't

(and I've fixed the crash)

I ended up rebuilding my server/backend yesterday because of a hard drive crash, I was pulling my hair out trying to figure out why XBMC front end wasn't working, seems I'm not the only one with this issue. Mythfrontend works fine obviously.

I'd like to rollback to 0.27.1 to get this working, is there somewhere I can find the .deb files for 0.27.1? I don't have them in my archive since I just did a fresh install yesterday...

I haven't been home much lately and my mythtv install is still on 27.1, but does anyone know if the problem still occurs with janbars new version of the mythtv addon?

http://forum.xbmc.org/showthread.php?tid=198833

(2014-07-01, 15:26)teeedubb Wrote: [ -> ]I haven't been home much lately and my mythtv install is still on 27.1, but does anyone know if the problem still occurs with janbars new version of the mythtv addon?

This probably isn't too helpful, but for what it's worth so far I haven't been able to get it to work with either 0.27.1 or 0.27.2. I always get a "Channel Unavailable" notifier in XMBC. However, it does not cause the "File too small" error message in the mythbackend log file that people have been seeing with cmyth and 0.27.2. It doesn't produce any errors at all as far as I can see, it just connects then disconnects. So it's possible I've got it configured wrong and it would work just fine with the new version.