Closed da3dsoul closed 5 years ago
In relation to this, an issue I came across: https://forum.kodi.tv/showthread.php?tid=341707
Heavy stuff. So you forking routing, yay. I would love to see someone answering you that thread
On March 6, 2019 11:54:53 PM GMT+01:00, da3dsoul notifications@github.com wrote:
In relation to this, an issue I came across: https://forum.kodi.tv/showthread.php?tid=341707
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bigretromike/nakamori/issues/297#issuecomment-470310513
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
"Forking" psh I'm done
So in the end you don't want to use Monitor
for handle player, that's resolve few issue with initial design. But why service need to hold playlist ? Playlist is object you can create like ListItems
it small exceptions. Wouldn't it be cool if service would handle data exchange with shoko ? you could queue things up, resume would be stable - because our overwriten Player
would just send signals
to stop, start, pause
it. If Calendar
is in script (because it need to because of Kodi architecture, will ListItem based on be in plugin or script ? Where you will put voting, resume, trakt?
Sorry your English in the second part is not readable for me... At least right now.
ListItem is the specific word for Kodi list items. They only exist in the player for setting media info and the menus.
Playlists are in service because otherwise they would be wiped or need a DB for persistence as soon as you hit play or entered a different menu. If it's in service, you can add episodes from anywhere, stop in the middle, etc.
Player is not in service because service can't access what it needs to.
Calendar is in script because it's not a built in list like all of our menus. Likewise, voting, resume, playback, scrobbling, etc aren't lists, and therefore go in script.
There is a list based calendar if you dont remember.
Second part is about making service
as middle men between Shoko API and Nakamori.
Like you throw command at service and service handle the communication betweeen shoko, that way if there is issue or later we have fully working client inside nakamori then service would handle queuting commands from nakamori that don't require instant replay. That way connection would be from plugin/script to service and service would exchange data with shoko api. Because I could imagine that you want to "Regroup collection", "valid images" and "download missing data" - you run those from "nakamori client" that got send to service queue, then you exit nakamori because you want to watch something outside nakamori while service would have queue and execute those "long run" task with ease in background.
Ah, I forgot about the old Calendar. Assuming we keep the old Calendar, it goes in plugin.
I don't need to put it in service to do long running tasks. I would just spawn a new thread. Those would also use new API, so it wouldn't block. I could use the BackgroundProgress for such things.
Okay, so it doesn't look like kodi-plugin-routing will be updated any time soon. Can you pull my fork of it and add it to the nakamori repo? I'll up the version so that it'll pull from there instead of the main kodi repo.
Until I have a proper implementation of inter-addon routing, we'll call things by URL if they are between different addons, but it needs to be easy to search and replace for later.
I'm gonna do something really fucked up from my minecraft days....It's not bad in some cases, but it is here.
NVM it won't work....I'm sad. I was going to do a regex replace in the build script to fix the issues...
I don't see issue with that but why not use the official one and replace URL so it don't conflict with each other ?
On March 10, 2019 8:42:16 PM GMT+01:00, da3dsoul notifications@github.com wrote:
Okay, so it doesn't look like kodi-plugin-routing will be updated any time soon. Can you pull my fork of it and add it to the nakamori repo? I'll up the version so that it'll pull from there instead of the main kodi repo.
Until I have a proper implementation of inter-addon routing, we'll call things by URL if they are between different addons, but it needs to be easy to search and replace for later.
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/bigretromike/nakamori/issues/297#issuecomment-471337208
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
What? Sorry the English is fine, but I don't know what you are referring to
You ask me to pull your fork of routing
, I understand that the issue with it is the url/<name>
and url/unsort
are the same when they aren't ? And you fixed that with your frok, so Im asking if we really need fork when we could just replace those urls with unique once ? Or it its not that problem ,then what your fork did fix?
Oh that's not all. I also made a version for scripts, automatic conversion of variables, and some other little fixes.
But wait, as I've been fixing more things
Also, playing files may need to go in plugin for now, only because I can't figure out how to pass it to script. I got watched states and other stuff, but not playing yet
^_^, oh ok. so you added so many stuffs that it really is something more 👍 I will be pulling it from your repo then, just change its addon name
Wait though, as I've not pushed the latest changes. I'm in bed, so I'm doing it right now.
Don't sweat, Im not doing it right now.
I will do it when its ready 👍
We're good for that now. I still need to do more settings things and implement the cache. You should test the transcoder.
ok, I will try to do that.
Hahaha... The irony
Okay, this is part of the rewrite, but there's so much there that this should have its own.
The things that I can think of off the top of my head that go into each:
plugin:
script:
service:
Add things and discuss as needed here