[Ayla]

Good news everybody: starting now, the mythtv addon is part of the official xbmc addon repository: http://github.com/opdenkamp/xbmc-pvr-addons/
Currently in version 0.5 (not yet with 0.26 support). We will release the version 0.6 (with bugfixes and 0.26 support) as soon as we get the remaining problems sorted out.

The development repository will not change, so if you want or need the latest software, keep using my repo.

Note for linux and osx users:
Due to the fact that the addon has a dependency to libmysqlclient, team xbmc cannot provide binary builds of the addon for linux and osx.
Because it's not trivial to tell if and which version of the lib and dependend libs are installed.
To build the addon from this repository, you need to run ./configure --enable-addons-with-dependencies.
Still its a huge advantage, because distro maintainers can easily provide binary builds of all official addons. (like ubuntu, openelec, ...).

Cheers,
Christian

Great new Christian

Just to be clear, when you write: "To build the addon from this repository, you need to run ./configure --enable-addons-with-dependencies.".

Is that when building from your github branch, or when building from the offical XBMC addon repo?

As an OS X user, would you recommend keep using your github repo?

[janbar]

Now I can't tune at all, and the backend is working, status even shows i'm watching the channel i tuned to via xbmc.
http://pastebin.com/MgUt3zMW

I restarted xbmc and was able to tune in. Then I changed a channel and it froze after 5s again.
http://pastebin.com/8JJpvZSs

Hope this helps!

Thanks, i read them.
But for me it is only rarely. I suspect a bug in mythtv because backend send 0 blocks when we request it. Also It is only when tune is bad and file could be containing lot of errors.

So try to use amplifier or something like.

Nota: Mythfrontend does not use remote transfer (via myth protocol) and read directly the file. So it is not affected by this bug.

In the first log, the recorder does not send the callback "chain updated" (probably no tune).
In the second it is the issue above. It start recordings , send blocks and then stop to send block requested.
In my case this problem happens only on channels where the signal is poor. It is difficult to build a workaround because for the addon it look like a sudden end of show.

[Aubrien]

With regard to having to stop and restart playback every 2 hours, I bet the buffer dries up and then you hit the buffer code that doesn't work very well for me either. When you stop and restart playback it fills the buffer from scratch again until it runs out again in another couple hours. When the addon reads 0 bytes from the backend it chokes up and doesn't always recover. I havn't heard of a fix for this yet except when I was playing around and reworked the buffer code not to read if there is no data available. I didn't let the read operation progress until the file had at least a certain size. This was so many versions ago that my method would have to be reworked again. I still believe that having the frontend try and force its way through reading 0 bytes of data is not as good as preventing the read 0 bytes in the first place.

@janbar
Any chance of reworking the buffer code to avoid the reading of 0 bytes in the first place? If you have a delay between shows or long channel changes then you hit the buffer code and it doesn't work very well. Thanks

[timmyj9]

i was using digital radio channels with mythtv 0.25 and xbmc-pvr frodo nightly with cmyth
just updated by mythtv backend to 0.26 and updated the cmyth add-on
however the digital radio channels are not working, it just seems to just say working then just give up
standard dvb-t stations seem to be alright

Code:

ERROR: CDVDDemuxFFmpeg::Open - error probing input format, pvr://channels/radio/All radio channels/2.pvr
INFO: AddOnLog: MythTV cmyth PVR Client: PVRClientMythTV::ReadLiveStream: Read 0 Bytes!
INFO: Previous line repeats 14 times.
ERROR: CDVDDemuxFFmpeg::Open - error probing input format, pvr://channels/radio/All radio channels/2.pvr
ERROR: CDVDPlayer::OpenDemuxStream - Error creating demuxer

[fetzerch]

Good news everybody: starting now, the mythtv addon is part of the official xbmc addon repository: http://github.com/opdenkamp/xbmc-pvr-addons/
Currently in version 0.5 (not yet with 0.26 support). We will release the version 0.6 (with bugfixes and 0.26 support) as soon as we get the remaining problems sorted out.

The development repository will not change, so if you want or need the latest software, keep using my repo.

Note for linux and osx users:
Due to the fact that the addon has a dependency to libmysqlclient, team xbmc cannot provide binary builds of the addon for linux and osx.
Because it's not trivial to tell if and which version of the lib and dependend libs are installed.
To build the addon from this repository, you need to run ./configure --enable-addons-with-dependencies.
Still its a huge advantage, because distro maintainers can easily provide binary builds of all official addons. (like ubuntu, openelec, ...).

Cheers,
Christian

Great new Christian

Just to be clear, when you write: "To build the addon from this repository, you need to run ./configure --enable-addons-with-dependencies.".

Is that when building from your github branch, or when building from the offical XBMC addon repo?

As an OS X user, would you recommend keep using your github repo?

Sorry. This effects everybody. Also people using my master.

So please build with ./configure --enable-addons-with-dependencies now!
I will update the wiki page.

Which branch to use? Well:
Everyone who is able to build the addon and is willing to accept that a development build might not only contain fixes but also include new problems is welcome to continue using the development branch. It helps us a lot if you guys provide debug logs.

BTW: Last night for some of us the DST (daylight saving time) changed. If you were affected and are using a 0.26 backend, it would be great if you can report new problems.
I recognized for example that setting the bookmarks and the watched state doesn't work any more.

Cheers,
Christian

[Aubrien]

@janbar
Are you located in the US? I doubt it because of your name but I was thinking about sending you my card so you can get the buffer code working and then send it back. I would pay of course. Unless there is another option. I have an HD PVR. Thanks

[fetzerch]

@all:
Now that the addon is also available in the official repo, we expect more and more users showing up the MythTV support category of this forum here: http://forum.xbmc.org/forumdisplay.php?fid=170
Surprisingly, I didn't know about it before, maybe it's also new for you.

I'd like to encourage you to check for new questions there from time to time and support the others if you can.

Cheers,
Christian

[janbar]

With regard to having to stop and restart playback every 2 hours, I bet the buffer dries up and then you hit the buffer code that doesn't work very well for me either. When you stop and restart playback it fills the buffer from scratch again until it runs out again in another couple hours. When the addon reads 0 bytes from the backend it chokes up and doesn't always recover. I havn't heard of a fix for this yet except when I was playing around and reworked the buffer code not to read if there is no data available. I didn't let the read operation progress until the file had at least a certain size. This was so many versions ago that my method would have to be reworked again. I still believe that having the frontend try and force its way through reading 0 bytes of data is not as good as preventing the read 0 bytes in the first place.

@janbar
Any chance of reworking the buffer code to avoid the reading of 0 bytes in the first place? If you have a delay between shows or long channel changes then you hit the buffer code and it doesn't work very well. Thanks

Hi aubrien,
Every days i think about your case. I can not explain why a "Read 0 bytes" is a problem. At each stream read addon try to query a block of bytes from backend. After trying for 30 seconds (because we added sleep for 0.5 s for each try) XBMC close playback. I think to simulate your case on my config using a stub of code.
Nota: The "Read 0 Bytes" is like a signal to tell us:
- get smaller block of bytes
- try to switch next file from chain if exists
- Retry read later because i am overloaded and i cannot send more bytes now

[janbar]

With regard to having to stop and restart playback every 2 hours, I bet the buffer dries up and then you hit the buffer code that doesn't work very well for me either. When you stop and restart playback it fills the buffer from scratch again until it runs out again in another couple hours. When the addon reads 0 bytes from the backend it chokes up and doesn't always recover. I havn't heard of a fix for this yet except when I was playing around and reworked the buffer code not to read if there is no data available. I didn't let the read operation progress until the file had at least a certain size. This was so many versions ago that my method would have to be reworked again. I still believe that having the frontend try and force its way through reading 0 bytes of data is not as good as preventing the read 0 bytes in the first place.

@janbar
Any chance of reworking the buffer code to avoid the reading of 0 bytes in the first place? If you have a delay between shows or long channel changes then you hit the buffer code and it doesn't work very well. Thanks

Hi aubrien,
Every days i think about your case. I can not explain why a "Read 0 bytes" is a problem. At each stream read addon try to query a block of bytes from backend. After trying for 30 seconds (because we added sleep for 0.5 s for each try) XBMC close playback. I think to simulate your case on my config using a stub of code.
Nota: The "Read 0 Bytes" is like a signal to tell us:
- get smaller block of bytes
- try to switch next file from chain if exists
- Retry read later because i am overloaded and i cannot send more bytes now

Sure, there is a bug somewhere. I found one and i suspect it comes from Myth (the case above when show stop). But i must check why. It could be an issue about how we implement the protocol. I am looking for.

[janbar]

@Aubrien,

Please try with this update: in file addons/pvr.mythtv.cmyth/src/cppmyth/MythRecorder.cpp line 169:

replace "while (*m_liveChainUpdated == 0 && i < 5000)" by "while (*m_liveChainUpdated == 0 && i < 60000)

It is not "Read 0 bytes". It is "Wait more time to get the backend callback".

If the backend does not send callback at time then there is nothing to read: We will reading always empty => Read 0 Bytes for ever.

If it resolves a part of issue, then Aubrien, we must re-add the "delay for channel switch" setting.

Nota: Get the last addon source ( think you need now to configure with option --enable-addons-with-dependencies)
Let me know. Thanks

EDIT: Sorry you had tried that before. And i re-read your log: You have the callback 8 second after starting playback.
But i can't explain why the show does not start before 30 seconds because addon has downloaded few Mega bytes of stream before (i counted 16MB) and only 1 or 2 is enough for the demuxer (ffmeg) to display show.

[janbar]

@Aubrien,

Please try with this update: in file addons/pvr.mythtv.cmyth/src/cppmyth/MythRecorder.cpp line 169:

replace "while (*m_liveChainUpdated == 0 && i < 5000)" by "while (*m_liveChainUpdated == 0 && i < 60000)

It is not "Read 0 bytes". It is "Wait more time to get the backend callback".

If the backend does not send callback at time then there is nothing to read: We will reading always empty => Read 0 Bytes for ever.

If it resolves a part of issue, then Aubrien, we must re-add the "delay for channel switch" setting.

Nota: Get the last addon source ( think you need now to configure with option --enable-addons-with-dependencies)
Let me know. Thanks

EDIT: Sorry you had tried that before. And i re-read your log: You have the callback 8 second after starting playback.
But i can't explain why the show does not start before 30 seconds because addon has downloaded few Mega bytes of stream before (i counted 16MB) and only 1 or 2 is enough for the demuxer (ffmeg) to display show.

Instead, you can try to increase the timeout of buffer code, like this: in file "lib/cmyth/libcmyth/livetv.c" line 926:
change "usleep(500000)" by "usleep(999999)" : You will have 60 seconds left instead 30 seconds. (don't update up to 999999 because it is not supported by function usleep on all os).

About your provided code in previous post: The problem is you lock all threads having need to update livetv chain to start the show as soon as possible. Yes it could be run but every time you wait for a long fixed period before start the playback without take care of backend callback: In your log, after 8 secs it tells you: Yes you can start to read the stream.

---

@janbar
Are you located in the US? I doubt it because of your name but I was thinking about sending you my card so you can get the buffer code working and then send it back. I would pay of course. Unless there is another option. I have an HD PVR. Thanks

I am french . There is a long journey. Save your money Aubrien. First i will reading the doc of HD PVR.

[rsennewald]

So i'm curious if anyone else has encountered this bug. I set a channel to be hidden on Myth backend, but on the XBMC front end it is not hidden from the EPG or listings. I have to manually go through and hide any channels that I don't want to see in XBMC separately. Shouldn't this be pulled from MythTV when loading the EPG? I've tried wiping the EPG database and resynching it, but it still doesn't care what channels are hiddein in mythtv. I want to hide every channel besides 701-799 (which I've done successfully in myth backend).

I just stumbled over this unanswered post. Maybe the answer is still helpfull for you or somebody else.
Right now changes to an existing channel on mythtv backend (like. visibility, channel icon, channel name, ...) are not propagated into xbmc automatically.
To get those changes you have to reset the pvr database. Resetting only the epg database does not help. (Settings -> LiveTV -> General -> Reset PVR database)

I will clarify if this is simply a bug or the desired behavior. You might have settings in the xbmc channel manager that would get overriden when reloading from the backend. (like scrapper, custom icon, ...)

Should be already fixed now in xbmc: https://github.com/xbmc/xbmc/commit/f679...3f19c3fbb8

Thanks for pointing this out. I just tried a new XBMC and cmyth addon build, reset the PVR database and sure enough it works as expected. The hidden channels don't show up in the EPG or channel lists anywhere on XBMC now, awesome!! I was getting so tired of scrolling through tons of pages to get to the HD stations (only ones I watch).

FWIW if anyone wants to mass update channels to have visible set to false (so they're hidden) in MythTV, its a couple of quick mysql statements. namely "UPDATE channel SET visible=0 WHERE channum BETWEEN $first AND $last;" Where $first and $last represent the boundaries for the channel numbers you want to make hidden.

[dst6se]

With regard to having to stop and restart playback every 2 hours, I bet the buffer dries up and then you hit the buffer code that doesn't work very well for me either. When you stop and restart playback it fills the buffer from scratch again until it runs out again in another couple hours. When the addon reads 0 bytes from the backend it chokes up and doesn't always recover. I havn't heard of a fix for this yet except when I was playing around and reworked the buffer code not to read if there is no data available. I didn't let the read operation progress until the file had at least a certain size. This was so many versions ago that my method would have to be reworked again. I still believe that having the frontend try and force its way through reading 0 bytes of data is not as good as preventing the read 0 bytes in the first place.

@janbar
Any chance of reworking the buffer code to avoid the reading of 0 bytes in the first place? If you have a delay between shows or long channel changes then you hit the buffer code and it doesn't work very well. Thanks

Hi aubrien,
Every days i think about your case. I can not explain why a "Read 0 bytes" is a problem. At each stream read addon try to query a block of bytes from backend. After trying for 30 seconds (because we added sleep for 0.5 s for each try) XBMC close playback. I think to simulate your case on my config using a stub of code.
Nota: The "Read 0 Bytes" is like a signal to tell us:
- get smaller block of bytes
- try to switch next file from chain if exists
- Retry read later because i am overloaded and i cannot send more bytes now

Sure, there is a bug somewhere. I found one and i suspect it comes from Myth (the case above when show stop). But i must check why. It could be an issue about how we implement the protocol. I am looking for.

I have the same problem as aubrien !
Im using a tbs5880 with a CI reader, when I select a channel , it will play for 6sec and then stop !
I never have the problem on HD channels, on some SD channels I may have to start 10 times before I dont get the "read 0 bytes".
If I use the mythfrontend it seems to be fine !

[janbar]

@dst6se
Yes, mythfrontend is not a remote front and it read directly the recorded file. It does not use the myth protocol to download the stream since 0.25. So that avoid many problems. Thanks for feedback. I try to find the evil who breaks our streams.

[raptorjr]

But Myth doesn't read the files directly when using storage groups, does it?