Remove locally stored state

[jocki84]

Hi @raptor2101, regarding #85 you are completely correct that the JSON files should not be downloaded before a programme is selected. This speeds up directory display tremendously.

However, I really dislike storing state on the server even if it helps to save a second download time. I have done some experiments without storing any state locally and I think the plugin is still very responsive.

I have also fixed a crash 37f6df1 as well as some minor bugs b351bcb.

I am quite sure that ORF playlists are broken by 8b2aedb, please review my submission 55e6e2a.

[raptor2101]

I mistakenly merged you pull request instead of cherry picking one commit

Storing files is currently the only option to bypass timing errors. Either you fully parse and display the whole json file at one's ore you storing it localy. Between two calls (loading main -> navigate into a section) could be few milliseconds or Hours. WorstCase: the json has changed and the path revering to a section currently not existing.

The IsPlayablke=true/IsFoolder False is intended and correct. Orf is currently also broken for an other reason.

i don't get qhy you remove all counters out of zdf.py?

[jocki84]

You're right, the path could get stale if the remote JSON file changes between the time of presenting the menu and processing a selection – however, storing the file locally doesn't really help since the information in the file itself could be out-of-date by the time the selection is made. I think nobody would expect a menu to work correctly that was opened last week, so in practice I think we can live with the pathological case of inadvertently presenting an incorrect folder contents because all the user needs to do for the menu to reload is to go back up.

I'm sorry I caused confusion regarding ORF, the change just seemed very odd and out-of-place in this commit that was addressing a completely different issue…

I removed the counter because the totalItems parameter of addDirectoryItem should be the total number of items that will be added to this directory rather than a running count of the items added so far. I'm aware that passing 1 is also incorrect though…

[raptor2101]

I'am pretty sure, that the playlist feature only works in old xbmc versions and was broken for a long time.

Regarding to the storedFiles: if i get it right, zdf works with hard links, so it's very unlikely that a link got outdated, despite the fact, that json file get old and a path walk ends in an error...

I encounter this problem during testing quite often (on my HTPC i'am havely using Suspend to Ram)

How did you grap these data (https://config-cdn.cellular.de/zdf/mediathek/config/android/4_0/zdf_mediathek_android_live_4_0.json) initialy from the app. Decompile the app or running a man in the middle proxie?

[raptor2101]

regarding to the counters, you are right. 1 is as good as every number. The Plugin is currently as fast as possible.

These counters are only usefull if more than one file is loaded (time delay...)

[raptor2101]

BTW: are you using some more "direct" communication methods like IRC/ICQ ore some "modern messengers"

this could prevent us both from doing stuff twice time :D

[jocki84]

To find the URLs I used mitmproxy running on (you probably guessed it) a Raspberry Pi 2.

[raptor2101]

Ahh ok the "XKCD"-Way (https://xkcd.com/538/) of accessing the data :D

[jocki84]

I happen to have the setup handy for security audits, but that's not to say it wouldn't be fun to try looking directly at the app ;)

[raptor2101]

You ignored my request for direct communication :D

Can you make a short look what kind of landing-json the ARTE App is using. Regarding to the JSON Structure i see so far, there is a good chance, that arte, phönix, 3sat using the same backend...

[jocki84]

I didn't, check your mailbox ;)

[raptor2101]

if you want to look into apk files look here http://www.javadecompilers.com/apk ;)

Currently browsing arte ;)