[liamf]

hi,

did a search but couldn't find any reference on this thread to mythtv versions older than 0.24.

I have an (admittedly reasonably prehistoric) mythtv backend. 0.23 + fixes, + (as far as I remember) a patched kernel on the very ancient PC it's running in.
Eden frontends on more modern diskless, mostly used to play content of a NAS.

I do use them with mythbox, and that works well enough for me.
I never use live tv on it, just recordings, and while it's a dodgy setup, it works "good enough".

If I upgrade to frodo for the fun, will it talk to the 0.23 backend?

I don't really want to touch that ancient backend machine until it dies of natural causes.

Thanks for your advice
Liam

[fetzerch]

I've seen issue reports with 0.23 recently. It seems that it does not connect.
Unfortunately the log didn't help to see what's wrong and I don't have a 0.23 setup here.

0.24 - 0.26 should work fine.

[romanodog]

I was using 0.23 and it did not work. I upgraded to 0.24 and it started working perfectly.

[liamf]

I was using 0.23 and it did not work. I upgraded to 0.24 and it started working perfectly.

OK, thanks.

Looks like I'll have to be brave and upgrade if I want to try it ;-)

[theli]

@cfetzer:

I have a 0.23 mythtv version. I can neither play recordings nor Live-TV with XBMC:

When I try to play a recording, I'm getting the following errors:
http://xbmclogs.com/show.php?id=33952

When I'm trying to play LiveTV, I'm getting:
http://xbmclogs.com/show.php?id=33955

[fetzerch]

I've seen issue reports with 0.23 recently. It seems that it does not connect.
Unfortunately the log didn't help to see what's wrong and I don't have a 0.23 setup here.

0.24 - 0.26 should work fine.

The logs don't help too much in this case. I'd strongly recommend to upgrade mythtv.

[hkramski]

Confirmed: I recently upgraded from 0.23 to 0.25 on my Ubuntu Lucid box and for the first time I'm able to watch live TV and recordings on my OpenELEC/Raspberry Pi. (EPG and timers were already working before.)

Heinz

[MvonSchantz]

I run XBMC 12.0 with MythTV 0.22+fixes, but to be able to do that I always have to patch cmyth_file_read() in lib/cmyth/libcmyth/file.c, so it supports reading 32 bit values instead of the 64 bit values that are used in modern MythTV versions. I think the following comment from the code in this function describes what's going on:

* MythTV originally sent back a signed 32bit value but was changed to a
* signed 64bit value in http://svn.mythtv.org/trac/changeset/18011 (1-Aug-2008).

Anyway, I just insert code here to conditionally read with cmyth_rcv_new_int64() or cmyth_rcv_long(), depending on the value of file->file_control->conn_version. I use cmyth_rcv_long() for conn_versions less than 57, but that's just a value I've made up. It works for 0.22+fixes.

[fetzerch]

I run XBMC 12.0 with MythTV 0.22+fixes, but to be able to do that I always have to patch cmyth_file_read() in lib/cmyth/libcmyth/file.c, so it supports reading 32 bit values instead of the 64 bit values that are used in modern MythTV versions. I think the following comment from the code in this function describes what's going on:

* MythTV originally sent back a signed 32bit value but was changed to a
* signed 64bit value in http://svn.mythtv.org/trac/changeset/18011 (1-Aug-2008).

Anyway, I just insert code here to conditionally read with cmyth_rcv_new_int64() or cmyth_rcv_long(), depending on the value of file->file_control->conn_version. I use cmyth_rcv_long() for conn_versions less than 57, but that's just a value I've made up. It works for 0.22+fixes.

Nice! You're more than welcome to contribute a patch, preferable as github pull request to https://github.com/fetzerch/xbmc-pvr-addons
And we'd include it to the pvr addon, assuming that it does not break newer versions.

Thanks,
Christian

[MvonSchantz]

You're more than welcome to contribute a patch, preferable as github pull request...
And we'd include it to the pvr addon, assuming that it does not break newer versions.

I'm afraid I'm not much of a git wizard... I can use it well enough to retrieve source code, but professionally speaking, I'm from the Microsoft school: with a TFS server I can do all the tricks I might need, but with git I'm less experienced.

As for breaking newer versions, there's one issue that must be considered: As far as I can tell from the changeset mentionend in the source code comment, the switch from 32- to 64-bit values was implemented around MythTV protocol version 40. The problem is, my MythTV 0.22+fixes is protocol version 50, and it's still using 32 bit values. So, something weird is going on, and I'm a bit unclear on what condition to use for properly determining if we should read 32- or 64 bit values.

I can't prove this, but I sort of have a feeling that the use of 32 vs 64 bit values isn't properly tied to a specific protocol number. I believe the translation of numbers into protocol strings is handled by Qt in MythTV, and around protocol version 40, MythTV was upgraded from Qt 3 to Qt 4, where Qt 3 wrote 32 bit values and Qt 4 wrote 64 bit values. Anyway, this upgrade to Qt 4 only took place in the new release of MythTV, and was never backported to fixes, and so there's one 0.nn+fixes out there that use protocol version 50 with 32 bit values, and another 0.mm without fixes that also use version 50 but with 64 bit values. (Really, I'm mostly just guessing here... I've been looking at the MythTV source code history, but I'm far from an expert on it.)

[theli]

In protocol version 66, the mythtv protocol switched from int,int to long values. The corresponding commits is:
https://github.com/MythTV/mythtv/commit/...cf5f5b88af

But there were other changes, that were done previously, e.g. for the FILL_POSITION_MAP command in protocol version 43:
https://github.com/MythTV/mythtv/commit/...62fb261989

or for the file-size property of the program-info array in protocol version 57:
https://github.com/MythTV/mythtv/commit/...8428becdee

But there seems to be no commit regarding the mythtv protocol (which mainly is located in mainserver.cpp) on 1-Aug-2008, see:
https://github.com/MythTV/mythtv/commits...server.cpp

The commit that was mentioned in cmyth/libcmyth/file.c seems to be the following:
https://github.com/MythTV/mythtv/commit/...12b11c839a
It only seems to be relevant for the upnp support.

Regards,
Martin

[MvonSchantz]

I think there has been two changes to the protocol here: first, the length was represented by a single 32 bit number (that's how 0.22+fixes (protocol 50) works). Then, it was represented by a 64 bit value split into two 32 bit numbers. And, finally, in current versions it's represented by a single 64 bit number.

The changeset from 1-Aug-2008 seem to be about the switch from Qt 3 to Qt 4, and the conversion from numbers to strings in the MythTV protocol seem to be handled by the QString class, which is part of Qt, so that's why I thought this change was introduced during the switch from Qt 3 to Qt 4. And that's why I thought it was an issue - because this change wasn't really made with the intention to change the protocol, but the protocol change was just a side effect of upgrading Qt, and so it might not be connected to a specific protocol version.

In any case, cmyth currently expects either two 32 bit values or one 64 bit value in cmyth_file_read(), but on older MythTV versions, there's only a single 32 bit value being sent, and so, cmyth_file_read() fails, unless it's patched to allow this third case as well.