[PinkFreud]

After successfully running XBMC 12 on Debian Wheezy on an older HTPC (quad core AMD 9350e, on-board ATI RS780 (Radeon HD 3200)), I recently upgraded to Debian Jessie and Kodi 14.2.

Suffice it to say, I had quite a shock. While most media played well on Kodi, an m2ts from a blu-ray I have did not - it had abysmal framerate and tearing. It was completely unwatchable.

I dug into the problem to figure out what was going on, and discovered http://kodi.wiki/view/Supported_hardware .

If that page on the wiki is correct, my RS780 is no longer supported by Kodi (despite that page also mentioning most hw from within the past 10 years should be supported - this machine dates back to 2008 or 2009, which is most definitely younger than 10 years!). I also note, with some bemusement, that Kodi still supports Radeon hw far older than this on Windows, which I am not, and will not be, running.

So, what happened?

It appears that Kodi switched to vdpau to support hw decoding of video. Debian Wheezy did not have vdpau support for ATI hardware, and as such, XBMC 12 did not appear to require it (can anyone shed some light on how the aforementioned m2ts played fine on this hw under XBMC 12?). By discarding the old hw decoding methods in favor of vdpau, I became subject to the hw limitations that vdpau exposed - namely, a lack of H264 decoding support in vdpau on the RS780.

A screenshot of 'o' while playing the m2ts on Wheezy w/ XBMC 12:
http://pinkfreud.mirkwood.net/kodi/wheez...enshot.png

A screenshot of 'o' while playing the m2ts on jessie w/ Kodi 14.2:
http://pinkfreud.mirkwood.net/kodi/jessi...enshot.png

Is my situation hopeless? Do I have to throw out perfectly working hardware which *used* to play back BR content just fine, all because Kodi no longer supports it? Or, is there something I can do to convince Kodi to use the older, *working* method of video decoding that my hw supports?

[Edit: img tags were not working - replaced those with links instead]

[Ned Scott]

From what I understand, the old decoding methods were outdated and broken and a major burden. The root of the problem seems to be with AMD's famously bad support for linux drivers when it comes to video decoding. The reason Windows can support older cards is because AMD puts more effort into supporting Windows than it does linux.

*shrug*

[Soli]

You're mostly on your own with Debian. Without a debug log, you're definately on your own.
I'm not doubting the wiki, but it doesn't hurt to try out a generic build of Openelec. Maybe you get lucky.

[wsnipex]

debian is (for once) not the issue here. AMD has simply abandoned older hardware from a driver pov. Fglrx has always been the worst driver ever and it still is today. The radeon driver is much better in terms of hardware video decoding, but anything < UVD2.2 is limited in terms of support. Since Kodi is OpenGL, we depend on gl_nv_interop, which is not implemented (and) not supported by older hardware.

I still have a box with rv 780 around that is rotting away, so I feel your pain, but have moved to proper hardware for my htpc(s) long ago.

[PinkFreud]

The radeon driver is much better in terms of hardware video decoding, but anything < UVD2.2 is limited in terms of support. Since Kodi is OpenGL, we depend on gl_nv_interop, which is not implemented (and) not supported by older hardware.

I refuse to touch AMD's proprietary driver with a 10 foot pole. The radeon driver is what I'm using for my hardware.

While I understand that anything older than UVD2.2 may be limited, the fact is, it *did* work. Is there a reason that UVD/UVD+ had to be dropped from Kodi, when that hardware (largely?) worked as-is? Even more to the point - is it possible to re-enable UVD/UVD+ support for older hw? Remember - this hardware is < 10 years old at this point, and there's still quite a bit of it out there. If Kodi is flexible enough to support UVD/UVD+ as well as UVD2.2 and newer, it'd be a pretty damn versatile htpc platform.

Thanks.

[Ned Scott]

When something gets dropped from Kodi it's normally because it needs to be dropped. A dev might be looking at code and trying to fix a problem or implement something, and the only reasonable way to do it is in conflict with the old support. They have to make a decision about that legacy support or being able to move forward.

[wsnipex]

what Ned said. Supporting platforms without gl_nv_interop was a dead end in terms of architecture and blocked new important features.
But you can happily continue to use the old version that worked for you.

[PinkFreud]

In that case, I suppose it's time to take another look at MythTV again. It looks like they support modern HTPC features, including an android remote, and from what I can tell from it's wiki, still has support for pre-UVD 2.2 hardware.

I simply lack the time and money needed to dedicate to running Kodi on here, apparently. XBMC worked well for me, but as tends to happen with old software, certain pieces (like the youtube plugin) gradually became less than useful. If updating it is no longer an option, my only recourse is to switch to another project. I initially abandoned MythTV for XBMC when MythTV became too much of a hassle to keep updated, and XBMC worked well. Since that's no longer the case, I have to find something else.

Thanks.