Download Frodo compatible test version here

(2013-01-11 07:54)Tolriq Wrote:  Yes it is

If on Xbmc Frodo RCx you can just force a rescrape, if on Eden you need to find the wrong NFO or MP3 tag that causes the problem

But shouldn't the encoding be correct even if there is 'bad' data in the information?
If not, wouldn't it be better to ignore anything incorrectly encoded?

As said this have been corrected on Xbmc for Frodo after my reports, they refused to add sanity checks on JSON side and on conversion from Eden.

So the only path left is to rescrape for users during the update to Frodo.

For what it's worth. I had the same problem with Yatse now. BUT if I change to Windows for the server with the same NAS holding the identical files, I don't have the problem anymore.

I just created an account to thank you for continuing the effort on this app! I banged my head for days trying to get the official one working on my new HTPC build. Found this one, installed it, worked instantly. YOU ROCK!

(2013-01-11 07:50)jblance Wrote:  OK - I've read up on the UTF8 encoding a bit

It does seem like the reply contains incorrectly code data, for example I am getting the above error with data like:
11000011 00100101, however the first 2 bits of the second byte should be 10

Similar problems happen with some 3 byte encodings

So I guess this means it is a problem at the XBMC end?

I think the fetching code should be lenient with respect to encoding exceptions. If a tag is malformed in an album list, it shouldn't really abort the whole operation. After all a tag is just a tag.

JSON rpc is a protocol if the data sent does not follow the protocol how do you want the client to understand ?

The specification is very clear about the fact that strings must be UTF-8 encoded, efficient json parsing needs a stream parser that analyse data as it comes, when some data should not be in the middle the parsers have no way to recover from that.

Xbmc should not be able to send data that does not follow the standard but it does if the data in it's database is not UTF-8 witch was possible until recent Frodo builds. (And will be in Frodo if you don't rescrape the bad data when updating from Eden).

This issue will be recurrent during update until all users rescrapes but well it was the chosen path by the Xbmc team.

(2013-01-11 21:47)Nat! Wrote:  I think the fetching code should be lenient with respect to encoding exceptions. If a tag is malformed in an album list, it shouldn't really abort the whole operation. After all a tag is just a tag.

Yeah - I've made a small change to the Jackson parser, so it just returns a space if the encoding is incorrect (instead of throwing an error)

This allows the remote to 'work' with bad data instead of failing with an error message. It works for me, will see if Tom is prepared to pull to his repo (as he seems to have the most current code)

Some of the needed tests to validate such an hack includes badly encoded utf8 just before an escaped " and as the last character of a string and some more I can't remember

Yeah I only addressed a small portion of the cases, though they seem to be the ones the are reported....

I didn't want to completely break the parser...

Lol yes I know but those 2 cases are user cases (I had lots of logs on this UTF8 problem )

And if your hack make the parser miss the " or the } then you'll completely break things with way more impact on the user