Jump to content

embyforkodi (next-gen) 6.X.X support


quickmic

Recommended Posts

quickmic

Yes, but there is still a major problem with kodi on Android. I'm currently looking for a workaround.

Android don't support multiprocessing for python 🙁

Edited by quickmic
Link to comment
Share on other sites

quickmic
Just now, arrbee99 said:

YouTube. 'Sign in to confirm your age' - for a Kodi video ?

Yes, for some reason, don't ask me why. I haven't enforced that.

Link to comment
Share on other sites

8 minutes ago, quickmic said:

Yes, but there is still a major problem with kodi on Android. I'm currently looking for a workaround.

Android don't support multiprocessing for python 🙁

Every second I see that libreelec in my rpi is the best way to use kodi.

Link to comment
Share on other sites

quickmic
On 10/10/2020 at 11:53 PM, kstilho said:

Every second I see that libreelec in my rpi is the best way to use kodi.

Basically, all Linux based Kodi will have an extra boost. Android have to deal with threading, not multiprocessing. Not sure if Apple TV is able to handle multiprocessing as well.

Fallback is threading mode, so 5.0.0 works on all devices. I will release a alpha next weekend, most of the bugs are already fixed. Just performing final tests...

Edited by quickmic
  • Like 1
Link to comment
Share on other sites

quickmic

A first alpha version is available.
Before you even think about testing, BACKUP THE COMPLETE KODI folder!
e.g.
/home/quickmic/.kodi/

If you don't know, how to do that and possibly restore it manually, STOP HERE!

 

Next step, wipe the complete Kodi folder (we start from scratch as a test!)
rm /home/quickmic/.kodi/* -R

Now you can sideload the alpha version from here:
https://kodi.emby.media/Public testing/next-gen-ALPHA-build192.zip


When you sync you database, DON'T USE ARTWORKCACHE!
This feature was and is still broken.

What is working:
regular filestreams
Transcoding (with limited options) No audiostream selection, not subtitle selection.

What is not working:
Almost all Playbackoptions in the settings menu are ignored beside network speed adjustment (based on that setting) Transcoding will be enabled
Multiserver support (most likely not working)
Contextmenu not working (even if available, don't use it!)

What is not tested:
Kodi 17
Apple TV


Multiprocessing is disabled for Android and Windows:

For Android (low power CPUs):
Don't use autoplay next movie. Actually you can use it, but it's a problem if Kodi generates playlist over a certain amount of recordsets. e.g. several thousands recordsets will stall Kodi and the local websocket will also stall!

For Windows it's quite likely that it will work too. Actually it depends on the CPU performance for Android and Windows.


If you are using custom skins, don't preview Photos on mainmenu Widgets. It works, but at the moment unstable.

 

This first version should only verify, if the Database sync and the regular filestreams are working.
Please, no feature requests at the moment, only bugreports. I'll add all the features after the playback modes are working perfectly.

Edited by quickmic
  • Like 3
Link to comment
Share on other sites

quickmic

Additional info:

Changing the network speed settings have only an effect after kodi restart.

Kodi shutdown not working.

Progress update is not working.

I'll release tomorrow a new version with a fix for shutdown and progress update.

Please observe if a database update (after playing file(s)) freezes Kodi. I experienced (sometimes) a crash but not quite often.

Edited by quickmic
Link to comment
Share on other sites

horstepipe
On 10/16/2020 at 4:39 PM, quickmic said:


When you sync you database, DON'T USE ARTWORKCACHE!
This feature was and is still broken.

 

 

Maybe a good time to discuss the right to live of this feature again. Kodi's internal artwork cache does a very good job. If you scroll through your library the needed artwork is being fetched from the server and permanently stored/cached to the thumbnails folder. I never felt the need to cache ALL artwork in advance. Besides that, this artwork (pre)cache is a heavy-weight cpu task for the server.  The server admin has no control over it, so if multiple users do this simultaniously the server becomes unreachable for everyone.

So just my personal opinion, drop this feature at all.

 

edit: Also low-powered client devices are completely overstrained by that task, which causes crashes -> corrupted database -> complaints here in the forums 🙂

Edited by horstepipe
Link to comment
Share on other sites

quickmic

Well, in general the pre-caching is not a bad option if it's working correctly and in the background as a low priority task. At least that's what I'm trying.

I use it for WAN clients to minimize delays while browsing threw the lists but still there is some research todo how to implement it.

And there are other issues with artwork caching at the moment. Caching uses nativ emby-server pathes. This works if you always use it from LAN or from WAN.

If cached artwork was performed in LAN and you access it from WAN, it will not work. -> e.g. Laptop

I tested to pipe it threw the webservice 127.0.0.1, but this could overload the local Socketserver.

Anyway, additional testing is required before I find a good approach.

 

 

 

Edited by quickmic
  • Thanks 1
Link to comment
Share on other sites

quickmic

Multiversion movies etc:

Currently I'm working on a good implementation for movie selection in different formats. Seems Kodi is not able to deal with it native.

If yes, please let me know how.

Current options are:

Add all versions nativ to Kodi-DB while sync, but not very fancy solution.

Manual selection on play, but this needs a playlist injection. That's exactly what I'm trying to avoid.

Fake a movie (URL-redirction) in Websocket, but this will not update TAG/Video infos. e.g. Directors cut will be longer than regular movie. Not tested what happens in such a case, but could cause issues.

Combine the movies via Boxsets, but not available in Widgets as regular movie.

Any ideas are welcome.

Edited by quickmic
Link to comment
Share on other sites

Psyborg
36 minutes ago, quickmic said:

Well, in general the pre-caching is not a bad option if it's working correctly and in the background as a low priority task. At least that's what I'm trying.

I also felt always that this a nice feature of Emby4Kodi that is not included in Emby itself. Pre-cached is often much faster in large libraries than immediately loading it from the network at that moment.

  • Like 1
Link to comment
Share on other sites

hello I tried to use but for some reason did not find my server I will try to reconnect later I believe it is a problem on the part of my server.

That said On the issue of grouping multi-version movies, there is a plugin for this on the emby as it uses boxset as a base. It works fine for me I only get one emby for kodi entry 

Link to comment
Share on other sites

horstepipe
2 hours ago, quickmic said:

Multiversion movies etc:

Currently I'm working on a good implementation for movie selection in different formats. Seems Kodi is not able to deal with it native.

If yes, please let me know how.

Current options are:

Add all versions nativ to Kodi-DB while sync, but not very fancy solution.

Manual selection on play, but this needs a playlist injection. That's exactly what I'm trying to avoid.

Fake a movie (URL-redirction) in Websocket, but this will not update TAG/Video infos. e.g. Directors cut will be longer than regular movie. Not tested what happens in such a case, but could cause issues.

Combine the movies via Boxsets, but not available in Widgets as regular movie.

Any ideas are welcome.

How did v19 handle this? For me it was fine. There was media info for only one version (random?), but that‘s not a deal breaker from my opinion.

Link to comment
Share on other sites

TeamB
2 hours ago, quickmic said:

I tested to pipe it threw the webservice 127.0.0.1, but this could overload the local Socketserver.

That's how we did it in the very first version, we did it this way then due to the emby server not supporting http HEAD for images and kodi requiring HEAD to check resource status before loading the image. It worked well and once kodi had the file cached locally it never had to load the image again so it scaled reasonably well. We dropped this approach when emby server added Head to the image endpoint.

In EmbyCon i cache images in the background one at a time while the screensaver in kodi is active. I have it so it triggers once when the screen saver is activated and then it listens for new content using the websockets and if new content is detected it triggers again. I found this works well.

 

 

  • Like 1
Link to comment
Share on other sites

Hello test results. The first thing I did was to delete the kodi app from my mi stick and install the supplied zip. The result was that it was not possible to read my library but the server connected,However, the library does not work. The solution was to install the stable version in the repository and then update it via the zip. I noticed an improvement in reproduction if it helps I can go up the logs if Required

Link to comment
Share on other sites

quickmic

Have you wiped your kodi database before you installed the alpha version? Actually, I had an issue updating the 4.X to 5.0 so I started from zero and then it worked perfectly.

Not sure if uninstall kodi app also removes the kodi user folder.

Edited by quickmic
  • Like 1
Link to comment
Share on other sites

quickmic
On 10/20/2020 at 8:55 PM, horstepipe said:

How did v19 handle this? For me it was fine. There was media info for only one version (random?), but that‘s not a deal breaker from my opinion.

Modification of playlist. I'll try that as well, but I don't wanna query the server for Video-info. This causes delays.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...