EoS Error

[ShayBox]

• Luna Version: Latest
• nVidia GeForce Experience Version: Latest
• Moonlight Embedded Version: Latest
• OSMC Version: Latest

Expected Behaviour:
Load game lost
Actual Behaviour:
EoS Error

So, clicking the host, shows its trying to get game info, for games that are installed, but not in the GFE list...
I only want steam to show up on the list, because Luna doesn't launch the game half the time...

But it closes the game loading screen shortly after and shows a check log EoS error.
I can get it to keep the screen up with an older version that doesn't use EoS, but does not progress forward.
Tried reinstalling OSMC multiple times.

I've tried disabling telemetry, disabling all game scrapers. etc... but it still tries to search for games despite me not wanting it to.

At one point it was slowly progressing through the game list in the past, but i've got over 50 games and it took almost an hour to scrape each game. I cannot deal with that speed.

Let me know if you need logs

[ShayBox]

Best solution would be to include more options.
Allow users to turn off game indexing.
Disable the new exception dialog closing
etc. if you add something, add a setting for it.

As it stands right now, I have to install r4, let it take over a week to index all the games, then update to r6 and clear the game cache. I'm not willing to do that.

[v4mpir0ck]

You can uninstall gfe in the host, delete al hidden folders in users/local/apps... And reinstall again, there will be only what you add manually El 22/2/2017 16:50, "Shayne Hartford" <notifications@github.com> escribió:

…

- Luna Version: Latest - nVidia GeForce Experience Version: Latest - Moonlight Embedded Version: Latest - OSMC Version: Latest *Expected Behaviour:* Load game lost *Actual Behaviour:* EoS Error So, clicking the host, shows its trying to get game info, for games that are installed, but not in the GFE list... I only want steam to show up on the list, because Luna doesn't launch the game half the time... But it closes the game loading screen shortly after and shows a check log EoS error. I can get it to keep the screen up with an older version that doesn't use EoS, but does not progress forward. Tried reinstalling OSMC multiple times. I've tried disabling telemetry, disabling all game scrapers. etc... but it still tries to search for games despite me not wanting it to. At one point it was slowly progressing through the game list in the past, but i've got over 50 games and it took almost an hour to scrape each game. I cannot deal with that speed. Let me know if you need logs — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#136>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYq-OvO0bdMufwq8mX5QnWUDdPdPc94Sks5rfFkxgaJpZM4MI0TF> .

[wackerl91]

@ShayBox Thanks for your feedback. You can find answers to your individual points below, but I took the liberty to group similar points from your two comments together.

Let me know if you need logs

Thanks to EOS, that shouldn't be necessary ...

EoS Error

... and that's not really an accurate description of the issue. From what I could gather by looking through the exceptions thrown today, requests to nvidia's GFE API were refused, which caused an exception. It's on my list now.

Tried reinstalling OSMC multiple times.

There's never any need to reinstall OSMC when Luna's misbehaving. Just delete the addon and the entire addon data for the Kodi profile in use.

So, clicking the host, shows its trying to get game info, for games that are installed, but not in the GFE list...

As @v4mpir0ck already hinted, this seems to be a GFE issue - the list is being pulled from the host and processed accordingly. Nothing is added or removed, there's only some caching for games that have been there before and are present after the refresh.

because Luna doesn't launch the game half the time...

Would be interesting why that is. Only get that when RE7 fails to launch, after which I have to reboot my host because everything else fails to launch as well. So far I've only encountered this with this single game and moonlight's output didn't show anything unusual. In fact, a streaming session is started and shows my Windows Desktop. If it doesn't do anything on your end then this might be worth investigating, but more information would be needed.

But it closes the game loading screen shortly after and shows a check log EoS error.
I can get it to keep the screen up with an older version that doesn't use EoS, but does not progress forward.
[...]
Disable the new exception dialog closing

Obviously this is absolutely intentional and there will be not option to disable this behaviour. First and foremost since on most occasions when an exception is fired while a dialog window is open it will lock up the entire UI, forcing you to restart Kodi.
Secondly because the exception handling is implemented as a decorator and is already a beast to deal with. I will not introduce a way to get a setting from the add-on (and thus more complexity) into a function that's designed to gather whatever it can. Before there's an argument about how disabling EOS works, as it's part of this process: differently, all class methods are replaced so they simply don't do anything (it's too late to remove the instance when I get information about it being enabled or disabled, plus other services shouldn't have direct access to the feature broker - but that's an architectonic decision).
The fact that it stays open in previous releases but doesn't progress should underline the importance of this being in place.

I only want steam to show up on the list
[...]
I've tried disabling telemetry, disabling all game scrapers. etc... but it still tries to search for games despite me not wanting it to.
[...]
Allow users to turn off game indexing

... because that's what Luna is designed to do. List all your installed games and gather additional information if you choose to do so (information from the host machine is always pulled).
Need to think about this, as it completely destroys the purpose of Luna in the first place.
To be fair, the easiest way to achieve what you want is to write a bash script and link it in your Kodi home screen - which is way easier than all the work put into Luna to make it what it is today.

i've got over 50 games and it took almost an hour to scrape each game. I cannot deal with that speed.

This is for two reasons mostly: some of the APIs are slow (especially TGDB, which is the only one that works right now) and parsing the results even more so if they are returned as XML as the results can be quite large (again, TGDB ...) and there's no cElementTree implementation on OSMC by default.
I'll look into this at some point (one idea is to provide proxied - and thus cached - access to APIs via EOS, but that's very obviously dependent on the ToS of different APIs), but not for some time. Not because this would be particularly complex, but it still takes more time then I can spend on this currently.
That being said, any help is always welcome. Neither Luna's nor EOS' code base is very complex, apart from all the underlying stuff (DI, routing, ...) which is built to make changes for potential contributors easier.

Best solution would be to include more options
[...]
if you add something, add a setting for it

This won't happen for everything that's added, the reason is pretty much the same as above for why there will be no option to disable closing the dialog.
Apart from that adding an option for every single possible thing takes way too much time. Implementing does and so does testing. And sh** can really hit the fan if I miss something, see #133.

As it stands right now, I have to install r4, let it take over a week to index all the games, then update to r6 and clear the game cache. I'm not willing to do that.

I really do not like the tone of that bit. Please always keep in mind that I'm doing this in my spare time and very obviously do not get paid for this, i.e. providing free software which is developed and maintained solely by myself plus providing support for all kinds of related or possibly unrelated issues (though I'm glad to say that the community seems to be growing and more people start to chime in). Yes, it is fun but it also took hundreds of hours so far, while still working and attending university.
I don't want to complain, even if it might sound like it ... but I just have to say that especially the last sentence comes off as ungrateful.
Still: there's a reason why the RC versions are marked as pre-released in contrast to the last really stable version. The release notes of the 0.7.-rc1 also reflect this by stating, that this will be the biggest update for Luna so far, including a new UI and a partial re-write of the underlying architecture.
If you want a more stable version, use 0.6.x and disable all the scrapers ;)

That being said: I do value the input of people who use Luna (maybe even a lot) and want to see certain features implemented and want to project to grow. I also got more than enough plans and ideas myself on making it better, faster and more user friendly than I actually have time for.

So - again - thank you for your feedback. As soon as I can find some time I will apply a fix that certain requests don't cause exceptions anymore and log their error instead.

[Kiina]

Still: there's a reason why the RC versions are marked as pre-released in contrast to the last really stable version

Well the last stable version is tagged as alpha. So normally it is alpha > beta > rc > rtm in terms of stability. So even though it is tagged as Pre-Release I expected the rc to be more stable then the alpha. So its basically the rc for v0.7.0-alpha?

[wackerl91]

Ever since 0.6.0 the more stable releases aren't tagged with GitHub's pre-release tag anymore. That distinction is needed to allow for differentiation between ... well, more or less stable releases and to give users the choice to update to the "latest and greatest" which will naturally be more error prone.
I had to make an easy distinction between those two kinds of releases for the update mechanism to work reliably, thus allowing users to actually get their hands on newer updates - and leveraging GH's tag was by far the easiest way to do so.

While you are correct about the general order of the lifecycle, it is beyond me why you would also ignore the context of the releases leading up to this point (especially the release notes for the initial 0.6.0 release).

Yes, bending best practices a bit ... but again, quick, easy and reliable solution. Alternative would have been to hold all updates back until they're "ready", but I thought it a good idea to allow early access and get feedback - which is the reason why so many things about 0.7.0 have been discovered (and fixed) so far.

Edit: was a bit out of line with the last sentence the night before, for which I'd like to apologise.
To also give a more straightforward answer to @Kiina's question: the plan was to release 0.7.0 without an alpha / beta tag when it's stable enough, but still staying under the magic 1.x mark because those releases should be "feature complete" and then only introduce smaller improvements / bugfixes (i.e. no major UI overhauls, no really huge new features that could potentially break stuff, ...).

As of right now, I don't know if this plan will hold up as expectations in terms of stability will naturally grow by then and so will the pressure on myself.
Which brings me to this point again: If you yourself (or anyone else reading it) should know their way around code (or would like to start getting into it; as mentioned before: most of the dark magic is in place to allow quick and easy extensibility without the need to know the details of the architecture. Additionally I'm always happy to teach others if I find the time), likes to write documentation or wiki entries, etc., any help is greatly appreciated. Just shoot me an email, the address is on my profile page.
(Which is essentially what I meant to say last night really, simply phrased properly this time)

[wackerl91]

@ShayBox
A proper solution for showing only Steam would be to introduce a filter system to the game list, which could be extended at some point to provide many more things than just hiding games.
What I have in mind (in short):

• each game entry will receive an additional flag to hide it individually, which can be controlled from the game's context menu. Steam (and potentially other launchers, if they ever introduce something similar to Steam's Big Picture mode) will be excluded from this option
• the default filter would be to hide all games with this flag (which would also not be superseded by other potential filters, i.e. it'd be an additional filter option)
• introduce a new setting to hide all games by default
• hidden games will not be processed by the scraper chain - neither during the initial index, nor on subsequent refreshes. If the aforementioned option is enabled, they will still be pulled from the host machine and saved as existing games, simply not shown or processed
• an exception from the above is if the filter option for the view is set to "show all": this would cause the scrapers to get additional information for all games when a list refresh is triggered (no automatic refresh, as you might want to only show all games to unhide specific ones and you wouldn't want that process to take ages just because getting the information is slow)

I think this would be inline with what you want (disabling the indexing altogether except for Steam) while still building a foundation for a more general filter (thinking genres, MP titles - if that information is available -, ...).
I'd be interested in your opinion and if this concept would indeed solve your problem.