All Activity

Hi, do you have any latest recordings?

No, not yet.

The docker exec fails: And I cant pull v2.2.5 right now, it says pulled newer image, but —force-recreate still builds 2.1.4. PS. You should check naming of releases, some have v2.x.x other without v. EDIT: Even though, after testing connection, refreshing and saving libraries again with 2.1.4.all Looks fine now

Will just add that if I use "Playback Correction" the sun is showing afterwards. So in my opinion now, this is a server issue that don't understand what works or not. And there should be an option for burn in of subs.

Okay, was just a guess as the plugin only works with what Emby gives it, so I sadly have little idea

I believe I have identified and solved your issue. I have adjusted the backend logic identifying libraries based on -arr source selection for the library media counter. Version 2.1.5 contains the fix and is available now. Thanks for all your help/feedback. The fix is much cleaner logic than I was using.

I have English set as my preferred language fetcher settings. I'll probably create a new post about it and see if anyone else is having issues. Thank you again!

The plugin takes the posters that emby gives it and draws on them, it does not dictate what to download. If I had to guess you don't use English and the posters for your language might be poor quality.

Emby.FastIptv.dll @Phyrate Added new version with scrollbar!

Thanks, this is very helpful. Based on the output, MediaSync is currently storing: Filme = movies Serien = unknown Kids = unknown Sabrina = unknown MediaSync isn’t identifying “Serien” as a movie library. It’s actually identifying it as unknown, and the dashboard count is falling back to a movie count. The next thing I want to check is what Emby is actually reporting back to MediaSync for your libraries. Can you run the following command and paste the output? docker exec mediasync python -c ‘from app.providers.media_servers.emby import EmbyProvider; import sqlite3,pprint; c=sqlite3.connect(”/config/mediasync.db”); row=c.execute(“select server_url, api_key from media_server limit 1”).fetchone(); p=EmbyProvider(row[0], row[1]); pprint.pp(p.get_libraries())’ This will show us exactly what Emby is returning for each library. Once we see that output, we’ll know whether this is an Emby library configuration issue, an Emby API behavior difference, or something MediaSync needs to handle differently.

Hi @MarvinB That (improved random functionality) feels much better to me. For me the next most important thing is easing the ability to play tracks. I think the skill is onto something asking the user to re speak if not heard properly, it gives me hope of something more but so far that just keeps the skill alive (which is promising and useful in itself). I wonder if the desired results can gradually be homed in on? The chance of getting the skillname, trackname and artist name and keywords all heard properly is ~10%. if the skill responded to track keyword / trackname with "which artist?/which Album?" and the user could specify "Artist None" (to remove artist filter) or "Artist Elton john" or "Album Honky Château" that might greatly improve recognition. You said Alexa has to return something to user within X seconds, Could a holding song or message be returned whilst the skill did more heuristic matching when not sure and then interupt the holding session. "Ask Alexa play X by Artist Y" "No confident match found, searching....." to give the skill a bit more time? If the skill could prioritise tracks where the artist is a member of album artists then you are more likely to get the best default version. Other than that my next priority on wishlist would be anything that can be done to improve recognition accuracy first time success. Make us of Musicbrainz search hints for odd sounding/spelt names https://musicbrainz.org/artist/7c20f558-d664-42bd-b6f1-81acf9dbb72d/aliases. Could popular artist names and tracknames feed into an accuracy improving engine? probably well past Alexa's capability/architecture but you did ask...:-)

It is possible that Emby does have those codes included, but that does not help much if the tool Emby uses to collect media information, FFprobe, cannot currently obtain the regional language code from the file. Because of that, it is impossible to properly distinguish between regional variants of the same language.

Hey! I had a similar issue once and it turned out to be browser-related. Clearing site data for Emby and testing in another browser helped narrow it down. Also worth checking if any extensions are interfering with the player controls. A bit unrelated, but when testing media playback on different devices I sometimes use tools like Pocket Speedometer to make sure there aren't any odd network or device performance issues affecting playback. Curious if anyone has found a consistent fix for this yet.

So first but of feedback On android auto, is there away you can show larger album covers as an option instead of just the lost as I find it easier to scroll the album than a list as such.

@yockerI have a question. Can EmbyIcons interfere with how Emby downloads covers / posters? For the past week since I've been really getting into setting up EmbyIcons, I noticed that every time I add a movie / tv show, Emby always grabs the worst possible quality poster. They are always the smallest size too being 200 x 300. I haven't changed anything in how Emby downloads metadata and images and this could be a coincidence, but it's happening with everything I add to Emby. I will try to trouble shoot later today by renaming the EmbyIcons DLL and rebooting and see if it still downloads poor quality images.

It might help to post the exact error message and which operating system you're installing on. I've seen Emby installs fail because of missing permissions, antivirus interference, or downloading the wrong package version. A screenshot of the error would make troubleshooting much easier.

still missing an automated way to update the streams via planned tasks in Emby.

Just to add a quick follow-up observation regarding this issue: I did some further testing and confirmed that if a non-admin user queries the single-item endpoint (GET /Users/{UserId}/Items/{ItemId}) or the playback info endpoint (POST /Items/{Id}/PlaybackInfo), the API correctly returns ALL available MediaSources for that episode. Since non-admin users clearly have the permission to view and access all merged versions via single-item requests, restricting the bulk listing endpoint (GET /Shows/{Id}/Episodes) to only return 1 MediaSource seems highly inconsistent and illogical. Currently, this inconsistency forces API consumers to make dozens of individual single-item requests just to build a proper version-aware season playlist. This completely defeats the purpose of having a bulk episodes endpoint and unnecessarily increases server load. Hopefully, this inconsistency can be addressed so that the bulk endpoint matches the behavior of the single-item endpoints.

There you go: docker ps --format "table {{.Names}}\t{{.Image}}" ('790522', 'Filme', 'movies') ('903989', 'Kids', 'unknown') ('903984', 'Sabrina', 'unknown') ('94171', 'Serien', 'unknown')

Hi! Thanks a lot for creating this plugin, I love it I just have a small suggestion that would make me love it even more: could it be possible to add a link in every item of the guide to the corresponding detail page of that item inside Emby? Basically the same as the "Go to item" button on a playlist item. That would be really helpful I think. Thanks!

This looks similar to the request I made for region codes. @Lukewere the English gb-826 and us-840 added to the beta also?

I am experiencing the exact same issue. Everything was working perfectly prior to the 4.9.0.x updates. However, after updating the server to the latest version, ⁠GetShowsByIdEpisodes⁠ returns significantly less data (incomplete ⁠MediaSources⁠) for non-admin users. This regression has been quite frustrating. I really hope Luke and the team can consider reverting to the previous logical behavior.

It does not. I blocked it some time ago. I occasionally unblock it for updates. Is an Internet connection required? If so I wasn't aware of that.

Hello PiliPili, ** This is an auto reply ** Please wait for someone from staff support or our members to reply to you. It's recommended to provide more info, as it explain in this thread: Thank you. Emby Team

Hi, I noticed a behavior change in recent Emby 4.9.x versions regarding the GET /Shows/{Id}/Episodes endpoint. Observed behavior: When calling this endpoint with Fields=MediaSources,Path to retrieve all episodes in a season: Admin account: Each episode's MediaSources array contains all available versions (e.g., 3 versions per episode if the item has 3 merged alternate versions). Non-admin account: Each episode's MediaSources array contains only 1 entry (the default version), even though the same item has multiple merged versions visible in the web UI. Steps to reproduce: Have a TV show with episodes that have multiple alternate versions merged together. Call GET /Shows/{SeriesId}/Episodes?SeasonId={SeasonId}&Fields=MediaSources,Path using an admin API key → each Item has multiple entries in MediaSources. Call the exact same endpoint using a non-admin user API key → each Item has only 1 entry in MediaSources. Additional observations: The single-item endpoint GET /Users/{UserId}/Items/{ItemId} with the same non-admin user does return all MediaSources correctly. So the limitation appears to be specific to the bulk episodes listing endpoint. The API documentation states this endpoint only "Requires authentication as user" with no mention of different response payloads for admin vs. non-admin roles. This also affects GET /Users/{UserId}/Items?Ids=... when querying multiple items at once — non-admin users receive only 1 MediaSource per item. Impact / Use Case: This change makes it impossible for non-admin users to programmatically build a season playlist that respects a specific version preference. For example: A user has a TV show where each episode has multiple merged versions (e.g., different subtitle/source variants). They want to play through the season using a consistent version. Previously, calling the Episodes endpoint once would return all MediaSources, allowing the client to pick the preferred version for each episode and build a coherent playlist. Now, non-admin users only see one (default) version per episode from this endpoint. The result is a playlist with mixed, inconsistent versions across episodes — some episodes get version A, others get version B, depending on whichever the server chose as default. The only workaround is to call the single-item endpoint individually for every episode in the season, which feels unnecessarily heavy when a single bulk endpoint used to handle this. Environment: Emby Server version: 4.9.5.0 OS: Linux (Docker) Questions: Is this an intentional change? If so, could the documentation be updated to reflect the difference in response between admin and non-admin users? If intentional, is there a recommended way for API consumers to retrieve all available MediaSources for a season's episodes in a single request as a non-admin user? Would it be possible to revert this behavior so that non-admin users receive the full MediaSources in bulk endpoints as before? This change has caused real inconvenience for users who rely on version selection to maintain a consistent playback experience across a season. Thanks for any clarification.