All Activity

For _thread it says 3.2 or greater for timeout. And the syntax might be slightly different for lock acquire/release I didn't check. lock.acquire(blocking=True, timeout=-1) Without any optional argument, this method acquires the lock unconditionally, if necessary waiting until it is released by another thread (only one thread at a time can acquire a lock — that’s their reason for existence). If the blocking argument is present, the action depends on its value: if it is False, the lock is only acquired if it can be acquired immediately without waiting, while if it is True, the lock is acquired unconditionally as above. If the floating-point timeout argument is present and positive, it specifies the maximum wait time in seconds before returning. A negative timeout argument specifies an unbounded wait. You cannot specify a timeout if blocking is False. The return value is True if the lock is acquired successfully, False if not. Changed in version 3.2: The timeout parameter is new. Changed in version 3.2: Lock acquires can now be interrupted by signals on POSIX.

I referred to the plugin at https://github.com/honue/MoviePilot-Plugins/tree/main/plugins/adaptiveintroskip, and used emby webhook method stop play the episodes when credits appear. Upon receiving a message from Emby, the plugin calls ChapterApi to add Credits chapter to the current and following episodes. The attachment is a piece of Python code I wrote that responds to webhook. You might be interested in taking it as a reference. To use this python file, you need add emby webhook first. webhook.py

Will check, but I use the low level apis from "_thread" like in the "queue.py" file

You're welcome. Of course the locks need to be used in the other functions that use ArtworkCache and DelayedContent. And if you really want to do it right if the threading library in kodi is new enough put timeout on the acquire calls, check that you actually got lock and fail appropriately if you did not. You can also put the critical sections in try-except blocks to make sure the lock gets released so one thread having an error doesn't bring the whole thing down with the others waiting on a lock that will never be released.

I referred to the plugin at https://github.com/honue/MoviePilot-Plugins/tree/main/plugins/adaptiveintroskip, and used emby webhook method stop play the episodes when credits appear. Upon receiving a message from Emby, the plugin calls ChapterApi to add Credits chapter to the current and following episodes. The attachment is a piece of Python code I wrote that responds to webhook. You might be interested in taking it as a reference. To use this python file, you need add emby webhook first. webhook.py

I think you did absolutely right. I'll double check and add i in the the code. Thanks for the great support, I really appreciate support from programmers.

Please see attached embyserver-63849686400.txt ffmpeg-transcode-61ae5d4d-e380-4867-8b16-620bc7c7479d_1.txt

Here's the same code with mutexs which in python are threading.Lock objects. Note I didn't actually run this, so it's a hopefully working example. At the top where you define ArtworkCache and DelayedContent globals also create your locks. ArtworkCacheLock = threading.Lock() DelayedContentLock = threading.Lock() Then in the function if QueryData['Type'] == 'picture': ArtworkCacheLock.acquire() if Payload not in ArtworkCache[1]: ArtworkCacheLock.release() xbmc.log(f"EMBY.hooks.webservice: Load artwork data into cache: {Payload}", 1) # LOGDEBUG DelayedContentLock.acquire() if QueryData['DelayedContentId'] in globals()['DelayedContent']: globals()['DelayedContent'][QueryData['DelayedContentId']][1] += 1 DelayedContentLock.release() xbmc.log(f"******************************* RACE COND 1 DELAY HAS {Payload}", 1) # LOGDEBUG client.send(f"HTTP/1.1 307 Temporary Redirect\r\nServer: Emby-Next-Gen\r\nConnection: close\r\nLocation: http://127.0.0.1:57342/delayed_content/{QueryData['DelayedContentId']}\r\nContent-length: 0\r\n\r\n".encode()) client.close() client = None return globals()['DelayedContent'][QueryData['DelayedContentId']] = ["",1] DelayedContentLock.release() xbmc.log(f"EMBY.hooks.webservice: Starting Delayed Content Load For {Payload}", 1) # DELETEME client.send(f"HTTP/1.1 307 Temporary Redirect\r\nServer: Emby-Next-Gen\r\nConnection: close\r\nLocation: http://127.0.0.1:57342/delayed_content/{QueryData['DelayedContentId']}\r\nContent-length: 0\r\n\r\n".encode()) client.close() client = None xbmc.log(f"EMBY.hooks.webservice: Load artwork data: {Payload}", 0) # LOGDEBUG # Remove items from artwork cache if mem is over 100MB ArtworkCacheLock.acquire() if ArtworkCache[0] > 100000000: for PayloadId, ArtworkCacheData in list(ArtworkCache[1].items()): globals()['ArtworkCache'][0] -= ArtworkCacheData[2] del globals()['ArtworkCache'][1][PayloadId] if ArtworkCache[0] < 100000000: break ArtworkCacheLock.release() if not QueryData['Overlay']: BinaryData, ContentType, _ = utils.EmbyServers[QueryData['ServerId']].API.get_Image_Binary(QueryData['EmbyID'], QueryData['ImageType'], QueryData['ImageIndex'], QueryData['ImageTag']) else: BinaryData, ContentType = utils.image_overlay(QueryData['ImageTag'], QueryData['ServerId'], QueryData['EmbyID'], QueryData['ImageType'], QueryData['ImageIndex'], QueryData['Overlay']) ContentSize = len(BinaryData) ArtworkCacheLock.acquire() globals()["ArtworkCache"][0] += ContentSize globals()["ArtworkCache"][1][Payload] = (f"HTTP/1.1 200 OK\r\nServer: Emby-Next-Gen\r\nConnection: close\r\nContent-Length: {ContentSize}\r\nContent-Type: {ContentType}\r\n\r\n".encode(), BinaryData, ContentSize) ArtworkCacheLock.release() del BinaryData DelayedContentLock.acquire() globals()['DelayedContent'][QueryData['DelayedContentId']][0] = ArtworkCache[1][Payload][0] + ArtworkCache[1][Payload][1] DelayedContentLock.release() xbmc.log(f"Loaded Delayed Content for {Payload}", 1) # LOGDEBUG else: # We still have the lock from above, get the data before another thread possibly overwrites it in the cache for over 100MB # but make a copy so we don't hold the lock during the full send toSend = ArtworkCache[1][Payload][0] + ArtworkCache[1][Payload][1] ArtworkCacheLock.release() xbmc.log(f"EMBY.hooks.webservice: Load artwork data from cache: {Payload}", 1) # LOGDEBUG client.send(toSend) return

Yes, but the subject is not correct. When I wrote this post I don't know that the problem is related with ASS subtitules

Is this the same discussion that we're having here?

The subtitles aren't embedding the font, but even when I use a tool to embed the font or change the font of the subtitles to Arial, the issue persists. Could it be due to a caching mechanism preventing the modified font from taking effect?

Here's my totally hacked up code that showed those print statements. I edited out some of the not so important ones. if QueryData['Type'] == 'picture': if Payload not in ArtworkCache[1]: xbmc.log(f"EMBY.hooks.webservice: Load artwork data into cache: {Payload}", 1) # LOGDEBUG if QueryData['DelayedContentId'] in globals()['DelayedContent']: globals()['DelayedContent'][QueryData['DelayedContentId']][1] += 1 xbmc.log(f"******************************* RACE COND 1 DELAY HAS {Payload}", 1) # LOGDEBUG client.send(f"HTTP/1.1 307 Temporary Redirect\r\nServer: Emby-Next-Gen\r\nConnection: close\r\nLocation: http://127.0.0.1:57342/delayed_content/{QueryData['DelayedContentId']}\r\nContent-length: 0\r\n\r\n".encode()) client.close() client = None return globals()['DelayedContent'][QueryData['DelayedContentId']] = ["",1] xbmc.log(f"EMBY.hooks.webservice: Starting Delayed Content Load For {Payload}", 1) # DELETEME client.send(f"HTTP/1.1 307 Temporary Redirect\r\nServer: Emby-Next-Gen\r\nConnection: close\r\nLocation: http://127.0.0.1:57342/delayed_content/{QueryData['DelayedContentId']}\r\nContent-length: 0\r\n\r\n".encode()) client.close() client = None xbmc.log(f"EMBY.hooks.webservice: Load artwork data: {Payload}", 0) # LOGDEBUG # Remove items from artwork cache if mem is over 100MB if ArtworkCache[0] > 100000000: for PayloadId, ArtworkCacheData in list(ArtworkCache[1].items()): globals()['ArtworkCache'][0] -= ArtworkCacheData[2] del globals()['ArtworkCache'][1][PayloadId] if ArtworkCache[0] < 100000000: break if not QueryData['Overlay']: BinaryData, ContentType, _ = utils.EmbyServers[QueryData['ServerId']].API.get_Image_Binary(QueryData['EmbyID'], QueryData['ImageType'], QueryData['ImageIndex'], QueryData['ImageTag']) else: BinaryData, ContentType = utils.image_overlay(QueryData['ImageTag'], QueryData['ServerId'], QueryData['EmbyID'], QueryData['ImageType'], QueryData['ImageIndex'], QueryData['Overlay']) ContentSize = len(BinaryData) globals()["ArtworkCache"][0] += ContentSize globals()["ArtworkCache"][1][Payload] = (f"HTTP/1.1 200 OK\r\nServer: Emby-Next-Gen\r\nConnection: close\r\nContent-Length: {ContentSize}\r\nContent-Type: {ContentType}\r\n\r\n".encode(), BinaryData, ContentSize) del BinaryData globals()['DelayedContent'][QueryData['DelayedContentId']][0] = ArtworkCache[1][Payload][0] + ArtworkCache[1][Payload][1] xbmc.log(f"Loaded Delayed Content for {Payload}", 1) # LOGDEBUG else: xbmc.log(f"EMBY.hooks.webservice: Load artwork data from cache: {Payload}", 1) # LOGDEBUG client.send(ArtworkCache[1][Payload][0] + ArtworkCache[1][Payload][1]) return

I did not, because the print statements are in the function that loads the artwork from emby. So all that mattered to me was the logic was being called twice overlapping. How that logic got called didn't matter to me, but it could be part of the double load problem.

Corection GET/HEAD I meant

I know what you mean Did you check it fore the same query type -> both GETs or both POSTs I assume yes, but just checking...

Here's a log example showing kodi does make the same request twice quickly. These are hasty print statements I threw in First request 2024-04-25 17:45:38.518 T:7718 info <general>: EMBY.hooks.webservice: Load artwork data into cache: /picture/8f96e117caea4dadacbfd99c712ad540/p-93861-0-B-3c409f0bdb2ba0c6302f25326f43dcb5 2024-04-25 17:45:38.518 T:7718 info <general>: EMBY.hooks.webservice: Starting Delayed Content Load For /picture/8f96e117caea4dadacbfd99c712ad540/p-93861-0-B-3c409f0bdb2ba0c6302f25326f43dcb5 Second request 2024-04-25 17:45:38.521 T:7719 info <general>: EMBY.hooks.webservice: Load artwork data into cache: /picture/8f96e117caea4dadacbfd99c712ad540/p-93861-0-B-3c409f0bdb2ba0c6302f25326f43dcb5 I intercept it here so it doesn't load it a second time from emby 2024-04-25 17:45:38.521 T:7719 info <general>: ******************************* RACE COND 1 DELAY HAS /picture/8f96e117caea4dadacbfd99c712ad540/p-93861-0-B-3c409f0bdb2ba0c6302f25326f43dcb5 blah blah blah lots of checking for delayed content to be loaded... End of first request when the content was actually loaded 2024-04-25 17:45:38.741 T:7718 info <general>: Loaded Delayed Content for /picture/8f96e117caea4dadacbfd99c712ad540/p-93861-0-B-3c409f0bdb2ba0c6302f25326f43dcb5

Yes exactly. You already have a global that is shared amongst all threads. And when you have that you must protect that only one thread access it a time. It's what critical sections and mutexes are for. The key phrase is "at any given time". It's a lock. A thread wants to do something so it tries to acquire the lock. If no thread is using it it gets the lock and does its thing. If another thread already has the lock the thread is blocked until the other thread is done. So critical sections must be short. So for example. Acquire lock: Check if global id already exists. If yes: increment counter release lock return if no: create id and set counter to 1 release lock actually load the image from emby Then when it's loaded and you're going to put it in global you grab the lock again just long enough to put it in the global dictionary and then release it. This is the standard way threaded programming works.

But it isn't the same thread. The "http://127.0.0.1:57342/delayed_content/blabla" redirects are all running as different threads, therefore it must be a global cache.

Hi There is a lot of problem with Emby for Apple TV app. Missing ABC list in the library side for fast search. Sometimes the app doesn't load the full library, I have got 1000+ movie in my library, yesterday I'm searching for Moana (in my language it called Vaiana) and the app only shows movies from 0 to L, closing the app then reopen solved this issue, but thats not a long time solution. Sorry for said that, but I hate the new login method, I have got little kids and for them is too complicated if last time I watched something (changing user) the old method after app opening shows the users, then they choose the correct user and watch what they want

Sounds like a mess. I see now it's your code doing the threading. From the sounds of the lock ups it's Kodi that should be doing the threading. Always sad when a UI locks up due to background processes. A simple counter as I did should be fine, and has very little extra memory growth. But the accesses to and logic around the globals should be in critical sections so that only one thread can be manipulating them at any given time, or so that any reaction is still appropriate. This is true regardless of how you solve the immediate problem being discussed. If you've done a lot of threading then I'm sure you know what i mean, but if not I can explain more or take a closer look at the code and make some mods.

We just got a new router and for some reason now most of our video content fails to play shortly after pressing play (<30 seconds), on Emby for Roku. The Roku device is the same one we've had for 3 years that's played all of this content just fine. BehaviorPlayback could begin at 0 seconds and go to 11 before snapping back to the content title card page. Or if I start playback in the middle of something it could play for up to 30 more seconds before snapping back to the title card. It has happened with the 10+ randomly picked pieces of media I've tried on. Some of the content is TV shows, some movies, some music videos, and also to recorded zoom calls. Some is direct play and some is transcoded. All of which was watched start to finish within the past month. Music (mp3s) can play well past a minute and don't cut out. Problem may be limited to video content only Platform & Versions Emby is served by docker via Docker Desktop on a windows 10 pc. The image is lscr.io/linuxserver/emby:latest and is up to date with 4.8.5.0, though the issue also occurred on 4.8.4.0. And we updated to 4.8.4.0 at least a week ago, well before the problem began today. I did rebuild the whole docker install Roku emby channel version Version 4.1.17. Roku STB 3920X Troubleshooting steps so far Isolate the problem. Content still plays fine in various browsers (chrome, edge, firefox) and apps (emby for windows) on different PCs (laptop; custom pc) and plays fine on emby android phone app. Transcoding and direct play both working. Restart emby server, docker desktop, and the hardware emby is served from. Restart Roku app Restart router. Restart modem. Verify everything in the stack is up-to-date including emby docker image, docker desktop, windows 10 on server and app on roku and roku device firmware Verify router settings. It's an upgrade from an older Asus to a newer Asus. All of the settings available are roughly the same. I can connect just fine. Logs don't show anything weird happening connection-wise. And, again, playback works fine on this network on other devices also on the network. I've checked the server logs to see if there's any errors. Hard for me to discern, so I am hoping one of you can point me in the right direction. I factory reset our Roku and re-set it all up manually (direct via local ip and port). It connects, displays media. When I press play, the problem persists and abruptly content ends within 30 seconds. embyserver (1).txt embyserver.txt

I'm actually planning on using an old second gen i3 machine to get her going. It's fast enough to transcode x264 1080p content to a Roku. It even sort of works on x265, but it makes the proc sweat, and if there's any hiccup the playback catches up with the transcoding. It'll get her started - and she'll either fall in love with it and I'll build out something better, or it won't click and all I'm out is my time (I have this stuff laying around). I was really hoping to start her out with something better out of the gate, but it might be better this way (for now).

Correct, it's not finally implemented yet. Not sure if Emby server reports the credit markers, it didn't in the past. How did you generate the credit markers on Emby sever? I never got it working.

It's not unusual for a WAN IP to change, even without a reboot of the device, and it's not a problem to get around this by using a DDNS. You may need to contact your ISP and find out if they allow opening a port, for it work for a short while and then stop either your WAN IP changed again or they're actively blocking after a short time.

Anyone who is not using hardware transcoding for 4k should just block non 4k capable users out from those libraries. Software transcoding 4k is absurd, and you should be using hardware, either Quicksync or NVENC. Both make trivial work of 4k transcoding. Even my old i3-8130u could handle 3 4k transcodes without a problem. If your hardware is not up to the task, upgrade. Heck an inexpensive N100 system will smoke an 8 core Ryzen in number of trancodes when using Quicksync.