[hdmkv]

BD titles ripped 1:1 via MakeMKV (except used ClownBD for TDKR) that exhibit the green pixellation/strobing issue on XBMC are:
- Bedtime Stories
- The Dark Knight Rises
- Django Unchained
- Gravity
- and probably more

Same titles muxed inside M2TS container play just fine.

[tennisbgc]

Do you do 1:1 rips of your own BDs? If so, I can give you several that demonstrate the problem and are 100% reproducible. The reality is that 95% or more of the folks here get their media in other ways than ripping it from discs they bought. You all know what I mean.

If we are getting out the "measuring stick" - I have a 16TB NAS in my basement which is 85% full of mostly 1:1 BD rips. I have purchased and ripped over 400 BDs... so while your experience is interesting it does not match my own. I have an i3 based HTPC with a GT430 running OE that plays all of these titles fine, it's just the FTV that has trouble... clearly for the torrent crowd this does not appear to be a concern, but some of us buy this stuff and don't want to transcode it just so it will play on one box.

Dont know about anyone else, but I'm certainly not trying to suggest that you arent seeing this problem, just saying that I havent. But then I keep most of my full bluray backups in ISO format.

However, comparing the performance of an i3, with a discrete GPU, and an optimised linux install, with this little box running a mobile phone operating system probably isnt a fair comparison.

For what its worth, I think the firetv is a great little box, which probably does more than we should expect for the cost. What I dont think it is, is suitable as the media source for a fully fledged home cinema setup, and to expect it to be is just asking too much. Although I wish it was

iso and m2ts are fine its just mkv

[Tinwarble]

BD titles ripped 1:1 via MakeMKV (except used ClownBD for TDKR) that exhibit the green pixellation/strobing issue on XBMC are:
- Bedtime Stories
- The Dark Knight Rises
- Django Unchained
- Gravity
- and probably more

Same titles muxed inside M2TS container play just fine.

First, there is already a bug report on this here: http://trac.xbmc.org/ticket/14997
Different results, but it is the same issue. I have both the Ouya and AFTV and both have the issue, however on Ouya you get the "rainbow colors" as were the AFTV has a green line/half black screen. But both devices have issues with the exact same files (in my case it's all 3 seasons of The Walking Dead)

Second, this doesn't seem to be a XBMC specific issue as I sideloaded MX Player on the AFTV and it has the exact same issue.

Third, this only happens with 1:1 1080p mkv/h.264. The original M2TS files as well as transcoded (Handbrake) mkv/h.264 files play fine.

[voip-ninja]

BD titles ripped 1:1 via MakeMKV (except used ClownBD for TDKR) that exhibit the green pixellation/strobing issue on XBMC are:
- Bedtime Stories
- The Dark Knight Rises
- Django Unchained
- Gravity
- and probably more

Same titles muxed inside M2TS container play just fine.

First, there is already a bug report on this here: http://trac.xbmc.org/ticket/14997
Different results, but it is the same issue. I have both the Ouya and AFTV and both have the issue, however on Ouya you get the "rainbow colors" as were the AFTV has a green line/half black screen. But both devices have issues with the exact same files (in my case it's all 3 seasons of The Walking Dead)

Second, this doesn't seem to be a XBMC specific issue as I sideloaded MX Player on the AFTV and it has the exact same issue.

Third, this only happens with 1:1 1080p mkv/h.264. The original M2TS files as well as transcoded (Handbrake) mkv/h.264 files play fine.

Thanks for pointing out the existing bug report. Unfortunately it appears that, from the bug report, nothing has happened with this bug for two months.

It seems (to me) that the most likely explanation based on what you have provided in the way of information is that this is a limitation in the device H.264 decoders themselves... and the only way to get it addressed would be to take it up with Amazon, etc. It is also possible the problem is a limitation in hardware, but that seems somewhat unlikely... drivers or firmware are more likely to me... problem with playback of possibly specific AVC H.264 profiles, etc.

Since Amazon likely has zero interest in supporting MKV I don't see this going anywhere. Since I rip a ton of BDs and MKV is what I like using in my work-flow (especially for things like forced subtitles, etc) I don't think I'm going to change everything around to accommodate FTV. Sadly it is not the box for me.

Thanks again for the info. I'll ship the FTV back to Amazon and perhaps keep tabs on this thread in the event something changes in the coming months. In the meantime I'll reconsider my earlier plan of picking up low end i3 NUC and seeing if for the somewhat higher cost I can get an acceptable Boxee Box replacement experience.

[deshwasi]

can someone point to the latest/greatest specific build that they have been using for at least couple days and that is reasonably stable? does the remote work in the virtual keyboard in any build? I tried the Helix nightly and gets stuck in bunch of places and virtual keyboard doesnt work.

[Tinwarble]

Thanks for pointing out the existing bug report. Unfortunately it appears that, from the bug report, nothing has happened with this bug for two months.

It seems (to me) that the most likely explanation based on what you have provided in the way of information is that this is a limitation in the device H.264 decoders themselves... and the only way to get it addressed would be to take it up with Amazon, etc. It is also possible the problem is a limitation in hardware, but that seems somewhat unlikely... drivers or firmware are more likely to me... problem with playback of possibly specific AVC H.264 profiles, etc.

Since Amazon likely has zero interest in supporting MKV I don't see this going anywhere. Since I rip a ton of BDs and MKV is what I like using in my work-flow (especially for things like forced subtitles, etc) I don't think I'm going to change everything around to accommodate FTV. Sadly it is not the box for me.

Thanks again for the info. I'll ship the FTV back to Amazon and perhaps keep tabs on this thread in the event something changes in the coming months. In the meantime I'll reconsider my earlier plan of picking up low end i3 NUC and seeing if for the somewhat higher cost I can get an acceptable Boxee Box replacement experience.

Well, I'm not sure if this is a problem with the AFTV or if it's just that XBMC and MX Player have the same problem (bug), but as I stated the Ouya has the same problem.

As far as Amazon supporting mkv, again as I stated it's not mkv specific because transcoded mkv's work fine it only happens with 1:1 muxes, but I'm not sure why everyone assumes that Amazon has no interest is supporting this or that. Just like I'm not sure why some people here think they have no interest in supporting VC-1. Instead of making those assumptions, if everyone that would like to have a certain issue address would contact Amazon about that issue then it's more likely that Amazon might find value in adding support for that issue.

The worst that can happen is that Amazon decides not to add support and the best is that enough people contact them and they find that it would add value to the device. After all it's a numbers game for Amazon, the more features the AFTV has the more desirable it will be for more consumers. Yes, Amazon is mostly concerned with supporting their services, however, unless people buy the AFTV and have it in their homes Amazon's services aren't going to matter if consumers buy a different product because it offers support that the AFTV doesn't.

And speaking of assumptions (which just makes a Ass out of U and Me), I'm not sure why some people think that Amazon is taking a loss on the AFTV. How much is it that some people think it costs to make and put out the AFTV? Of course Amazon is not making the usual 300%-400% markup that is usually on electronic devices, but it is highly unlikely that Amazon is taking a loss on the AFTV.

[voip-ninja]

Thanks for pointing out the existing bug report. Unfortunately it appears that, from the bug report, nothing has happened with this bug for two months.

It seems (to me) that the most likely explanation based on what you have provided in the way of information is that this is a limitation in the device H.264 decoders themselves... and the only way to get it addressed would be to take it up with Amazon, etc. It is also possible the problem is a limitation in hardware, but that seems somewhat unlikely... drivers or firmware are more likely to me... problem with playback of possibly specific AVC H.264 profiles, etc.

Since Amazon likely has zero interest in supporting MKV I don't see this going anywhere. Since I rip a ton of BDs and MKV is what I like using in my work-flow (especially for things like forced subtitles, etc) I don't think I'm going to change everything around to accommodate FTV. Sadly it is not the box for me.

Thanks again for the info. I'll ship the FTV back to Amazon and perhaps keep tabs on this thread in the event something changes in the coming months. In the meantime I'll reconsider my earlier plan of picking up low end i3 NUC and seeing if for the somewhat higher cost I can get an acceptable Boxee Box replacement experience.

Well, I'm not sure if this is a problem with the AFTV or if it's just that XBMC and MX Player have the same problem (bug), but as I stated the Ouya has the same problem.

As far as Amazon supporting mkv, again as I stated it's not mkv specific because transcoded mkv's work fine it only happens with 1:1 muxes, but I'm not sure why everyone assumes that Amazon has no interest is supporting this or that. Just like I'm not sure why some people here think they have no interest in supporting VC-1. Instead of making those assumptions, if everyone that would like to have a certain issue address would contact Amazon about that issue then it's more likely that Amazon might find value in adding support for that issue.

The worst that can happen is that Amazon decides not to add support and the best is that enough people contact them and they find that it would add value to the device. After all it's a numbers game for Amazon, the more features the AFTV has the more desirable it will be for more consumers. Yes, Amazon is mostly concerned with supporting their services, however, unless people buy the AFTV and have it in their homes Amazon's services aren't going to matter if consumers buy a different product because it offers support that the AFTV doesn't.

And speaking of assumptions (which just makes a Ass out of U and Me), I'm not sure why some people think that Amazon is taking a loss on the AFTV. How much is it that some people think it costs to make and put out the AFTV? Of course Amazon is not making the usual 300%-400% markup that is usually on electronic devices, but it is highly unlikely that Amazon is taking a loss on the AFTV.

What it boils down to, for me personally is how much time and effort I have to invest vs the likelihood that something is going to be fixed. In the minds of many 'MKV == pirate' and I strongly suspect that Amazon will absolutely not do things that might make their content partners question their commitment to upholding truth, justice and the DRM way.

Personally I find the likelihood of VC1 being fixed very remote, maybe 1%. If the problem with MKV playback is related to the version of FFMPEG libraries being used in XBMC, that will take quite a while to fix as the version is not supposed to be uplifted until the next major release.

If I have to spend even an hour or two patiently explaining to idiot first level Amazon support what it is that's not working, it's probably not worth the brain damage compared to spending $150 more for something that will do more of what I want.

As far as cost on electronics, at the retail level the markups are not 300-400%, that is actually a lot more than even manufacturers like Apple make, who have massive scale... an iPhone that costs $220 to produce they sell to carriers for something like $500.... and that doesn't account for their costs providing warranty and technical support, not to mention the massive R&D overhead of building such a device and OS.

On the FTV even if Amazon is able to build the box for $25 they might be only breaking even on it when all the costs are factored in and assuming a $99 retail price.

[Set845]

I haven't seen this mentioned anywhere in this thread but more than a few times I've lost my Confluence skin settings upon restarting XBMC. All settings revert to defaults. This has happened on two FTVs running Gotham stable. I tried restoring a backup guisettings.xml that I had stashed somewhere else on the box using XBMC file manager but that had no effect. My settings were not restored. So I tried renaming guisettings.xml to guisettings.xmlold and restarted XBMC. I then deleted guisettings.xml and renamed guisettings.xmlold back to guisettings.xml and resarted XBMC again. But my settings were not restored. Is this a permissions problem because we don't have root? Im a little worried because this seems to happen too often with no way to backup guisettings using the file manager.

Edit: I copied the guisettings.xml file to my Mac and deleted it on the FTV. I restarted the FTV and saw that my settings were gone of course and deleted it again. I quit XBMC and copied it back from the Mac to the FTV and launched XBMC. The guisettings were restored. Its looking like a permissions problem to me. I'm surprised no one else has gotten corrupted guisettings or otherwise lost them.

[ixian]

Thanks for pointing out the existing bug report. Unfortunately it appears that, from the bug report, nothing has happened with this bug for two months.

It seems (to me) that the most likely explanation based on what you have provided in the way of information is that this is a limitation in the device H.264 decoders themselves... and the only way to get it addressed would be to take it up with Amazon, etc. It is also possible the problem is a limitation in hardware, but that seems somewhat unlikely... drivers or firmware are more likely to me... problem with playback of possibly specific AVC H.264 profiles, etc.

Since Amazon likely has zero interest in supporting MKV I don't see this going anywhere. Since I rip a ton of BDs and MKV is what I like using in my work-flow (especially for things like forced subtitles, etc) I don't think I'm going to change everything around to accommodate FTV. Sadly it is not the box for me.

Thanks again for the info. I'll ship the FTV back to Amazon and perhaps keep tabs on this thread in the event something changes in the coming months. In the meantime I'll reconsider my earlier plan of picking up low end i3 NUC and seeing if for the somewhat higher cost I can get an acceptable Boxee Box replacement experience.

Well, I'm not sure if this is a problem with the AFTV or if it's just that XBMC and MX Player have the same problem (bug), but as I stated the Ouya has the same problem.

As far as Amazon supporting mkv, again as I stated it's not mkv specific because transcoded mkv's work fine it only happens with 1:1 muxes, but I'm not sure why everyone assumes that Amazon has no interest is supporting this or that. Just like I'm not sure why some people here think they have no interest in supporting VC-1. Instead of making those assumptions, if everyone that would like to have a certain issue address would contact Amazon about that issue then it's more likely that Amazon might find value in adding support for that issue.

The worst that can happen is that Amazon decides not to add support and the best is that enough people contact them and they find that it would add value to the device. After all it's a numbers game for Amazon, the more features the AFTV has the more desirable it will be for more consumers. Yes, Amazon is mostly concerned with supporting their services, however, unless people buy the AFTV and have it in their homes Amazon's services aren't going to matter if consumers buy a different product because it offers support that the AFTV doesn't.

And speaking of assumptions (which just makes a Ass out of U and Me), I'm not sure why some people think that Amazon is taking a loss on the AFTV. How much is it that some people think it costs to make and put out the AFTV? Of course Amazon is not making the usual 300%-400% markup that is usually on electronic devices, but it is highly unlikely that Amazon is taking a loss on the AFTV.

It's not an assumption; just look at the iFixit teardown: http://www.ifixit.com/Teardown/Amazon+Fi...down/23856

Based on the components (even assuming Amazon, being Amazon, gets the best bulk pricing, which may not actually be the case), manufacturing, packaging - that box easily comes close to the $99 price and that doesn't factor in the sunk costs of development specific to the TV portion of FireOS at all.

Whatever the case - even if they make, say, $10 a box off the thing - you can be sure that is not the motivation behind it. They are interesting in selling a box to sell services. It is not a long stretch to imagine that additional development, licensing/IP fees, and associated support costs for features that don't leverage selling their services are not a concern for them.

Making a box more attractive to a community that sideloads an app that completely side-steps their services in favor of "local" media obtained from sources other than Amazon or companies that pay Amazon is not on their radar. This is not pure speculation, it is simple common sense. Understanding what motivates them actually helps this community in the long run.

It's a great little box for $99 USD. It'll be even better if they allow that XBMC on Fire app in the store (which the more I think about it the more I think they will - I mean they still to this day allow an "XBMC" app that is not XBMC but totally rips off the icon and name in to the official store).

The rest of the limitations need to be understood and if it's possible - and if the volunteer community sees enough interest - worked around. Some things like the refresh rate issue probably won't be (unless maybe it gets a stable and easy root). Others, may be.

That's just my opinion though, by all means lobby them to pay to include VC-1 support or better mkv support for pirated media if you must. Stranger things have happened.

[hdmkv]

Third, this only happens with 1:1 1080p mkv/h.264.

Not all, just some. That's what weird.

[Tinwarble]

It's not an assumption; just look at the iFixit teardown: http://www.ifixit.com/Teardown/Amazon+Fi...down/23856

Based on the components (even assuming Amazon, being Amazon, gets the best bulk pricing, which may not actually be the case), manufacturing, packaging - that box easily comes close to the $99 price and that doesn't factor in the sunk costs of development specific to the TV portion of FireOS at all.

Whatever the case - even if they make, say, $10 a box off the thing - you can be sure that is not the motivation behind it. They are interesting in selling a box to sell services. It is not a long stretch to imagine that additional development, licensing/IP fees, and associated support costs for features that don't leverage selling their services are not a concern for them.

Making a box more attractive to a community that sideloads an app that completely side-steps their services in favor of "local" media obtained from sources other than Amazon or companies that pay Amazon is not on their radar. This is not pure speculation, it is simple common sense. Understanding what motivates them actually helps this community in the long run.



It's a great little box for $99 USD. It'll be even better if they allow that XBMC on Fire app in the store (which the more I think about it the more I think they will - I mean they still to this day allow an "XBMC" app that is not XBMC but totally rips off the icon and name in to the official store).

The rest of the limitations need to be understood and if it's possible - and if the volunteer community sees enough interest - worked around. Some things like the refresh rate issue probably won't be (unless maybe it gets a stable and easy root). Others, may be.

That's just my opinion though, by all means lobby them to pay to include VC-1 support or better mkv support for pirated media if you must. Stranger things have happened.

Yes, I have seen the iFixit teardown, but I'm not sure what that has to do with the price of tea in China. It is still an assumption because no one but Amazon knows what the cost is, that by definition is an assumption. Is it $1, $10, $20, etc., you nor anyone else can say for sure, so you make the assumption that it's a loss or a small markup.

I'm also unsure why you would assume or state "better mkv support for pirated media", since ALL my media is media that I own. Again, you make another assumption I guess or perhaps that is how you get your media.

As far as side stepping with sideloading, this is a developers tool. A developers tool because Amazon wants as many apps as possible on their device to make it more attractive to their consumers. Some of these apps will make Amazon money others will not (at least not directly), but Amazon probably makes another assumption, that is that even consumers who may use the device for things that doesn't make them money at first they will eventually buy apps or pay for services that they do make money on. This too is common sense and a common marketing strategy.

But being a naysayer and saying that contacting Amazon is a useless endeavor does not help anyone, since saying that they will do nothing about it is just an opinion. I would not presume to think to know what Amazon thinks is in it's best interest or what they will do or want do. However, I do know that it hurts no one to sit down and write an email in an attempt to let Amazon know that they would like to see support for things that the AFTV doesn't not currently support.

Also, as for VC-1, this is part of the email that I just received:

I'm sorry for the trouble you had. This is definitely not, what we want our customers to experience.

Please understand we completely depend on the manufacturer of the devices. And, I completely agree with your feedback. (Which what I stated is that they shouldn't have VC-1 on the main page if it is not supported)

I see that our technical team is already aware of it and are making agreements with the manufacturer of the devices to make it available at the earliest.

I’ve also taken this as a feedback and forwarded it to our Amazon Instant Video team, to make it available at the earliest and also to minimize the chances like these happening again. Customer feedback like yours is very important in helping us continue to improve the experience of our digital service.

Also, they gave me a $5 credit, so not only does it not hurt to contact Amazon, it may pay off for others to do so.

[Ned Scott]

If the issue is at Amazon's level where Amazon needs to fix something, then they'll probably fix it regardless of what file container it is in. The way this hardware decoding stuff works is that things at that level don't care what the file container is. This is just a guess, but if the file container is making a difference then it's probably an XBMC level issue and needs to be fixed there. Amazon never even needs to know you play MKVs.

That being said, if someone could upload a sample file (or point out one that might have already been posted, if I missed it) that demonstrates this issue, I would be your new best friend. I'm attempting to collect various test files in general, plus I'm interested in the progress of this issue directly.

[voip-ninja]

That's just my opinion though, by all means lobby them to pay to include VC-1 support or better mkv support for pirated media if you must. Stranger things have happened.

Why do you assume MKV equals pirated? I buy all of my stuff. I rip to MKV because it offers the most flexibility for the least space without comprising original quality.

The point I was making is that the industry assumes MKV equals pirated.

---

If the issue is at Amazon's level where Amazon needs to fix something, then they'll probably fix it regardless of what file container it is in. The way this hardware decoding stuff works is that things at that level don't care what the file container is. This is just a guess, but if the file container is making a difference then it's probably an XBMC level issue and needs to be fixed there. Amazon never even needs to know you play MKVs.

That being said, if someone could upload a sample file (or point out one that might have already been posted, if I missed it) that demonstrates this issue, I would be your new best friend. I'm attempting to collect various test files in general, plus I'm interested in the progress of this issue directly.

Ned I will clip a sample and put it on dropbox for you shortly.

[Doomsday01]

can someone point to the latest/greatest specific build that they have been using for at least couple days and that is reasonably stable? does the remote work in the virtual keyboard in any build? I tried the Helix nightly and gets stuck in bunch of places and virtual keyboard doesnt work.

If you have the game controller or a compatible one paired, You can use the game controller hats to move around in the virtual keyboard.

[MrCrispy]

The industry as a general rule has decided not to support the mkv container, because they assume, rightly or wrongly, that most media in that format comes from you know where. Nothing supports mkv - Ps3, Xbox, Chromecast, any media player etc. Put the same file in a mp4 container and all of them will play it. Its just a sad state of affairs.