All Activity

That was a nice line of thought. And if that is truly the case (your test strongly indicates it is), it should absolutely not be happening, polluting one library with content from another - regardless of metadata - is utterly unacceptable, under no conditions. @Luke

Just checked the Plex and JF integration, PleNx is a fork of the JF app Switchfin, should be possible to add API support for Emby. Other than that, it needs a hacked Switch with homebrew, unfortunately not native.

I do have local network access granted. The issue is only when accessing through Tailscale. When I'm connected to WiFi at home, music plays with no issues. When I'm connected through Tailscale but access Emby through the Safari browser the music plays fine. It's just when accessing through the iOS app the music will not play and just rapidly moves through the playlist.

Yeah, I have a build ready, but it's not tested. I'll send you a PM if you want to help me test it out

my "Audio Books" library was deleted and rebuilt with same results as described above. Log file attached. If Emby can't be trusted to display only files that are in the chosen folder, what's the point of choosing a folder? This seems a serious flaw that would cause havoc in every library. embyserver.txt

I was wondering if there is maybe a way to set up EMBY without messing around with DSM?

Hmm, why use Emby to delete files? I know its convenient, but is it safe? I always you filesystem to manage this, as I don't trust Emby to do the right thing. Hence my media is mounted as RO.

Hi, I don't use Audiobooks myself, but have a suspicion of what may be occurring... If you have identical tags in common fields, across both your Audiobook library and your Music library (even with completely different paths) then you may get cross-pollution between the two. From your screenshot example, it appears to be "Various Artists" and "Various" and "Unknown". If these are common across Authors/Artists or Books/Albums, then the problem will perhaps occur. I just did a small test to confirm - created an Audiobook library with one unique book/album - changed Album Artist on one track to "Various Artists" and then suddenly 45 Albums from my music lbrary appear. So perhaps have a look at this and make the tags unique to your two libraries. e.g. change "Various Artists" to "Various Authors" or whatever, and see if that stops the cross-pollution?

I checked it seems they not using cgnst.

Please try the 2.4.0 app update and see how things compare. Thanks.

Emby Windows, 2.315.2.0 Download a movie or video. I used "Original" quality for my tests. Wait for the download to complete successfully. Download the *same* movie or video. The second download shows in "Manage Downloads" as "Waiting to transfer" and stays that way. No new download takes place and no progress bar is shown in Downloads>Settings. No new entry shows in BITS manager. After deleting the original completed download and restarting the client, the new download progresses normally and completes. Expected behavior: No new entry should be created in "Manage Downloads". A warning or error could be displayed stating that the item was already downloaded, though for some use cases (e.g. multi-select) I'd prefer it if the duplicate downloads were just silently skipped and ignored.

Hi, did you see this?

No, I didn’t. Can I check this myself or I have to contact them?

@Iquaba?

If you can, make sure GitHub repos with plugins get attested. This forces them to build their plugins using GitHub workflows, which records the SHA256 hash and saves it. Then, a DLL can be checked against the GitHub API to verify if it was truly built by GitHub or if you're dealing with a MITM fake. Here's a PowerShell example, but you can use the API method with any DLL too. $digest = (Get-FileHash $file -Algorithm SHA256).Hash.ToLower() $verified = $null if (Get-Command gh -ErrorAction SilentlyContinue) { gh attestation verify $file --repo <user>/<repo> 2>$null if ($LASTEXITCODE -eq 0) { $verified = "attestation (gh)" } } if (-not $verified) { # No gh (or it failed): query the attestations API directly by digest. try { $att = Invoke-RestMethod -Headers @{ Accept = "application/vnd.github+json" } ` -Uri "https://api.github.com/repos/<user>/<repo>/attestations/sha256:$digest" if ($att.attestations.Count -ge 1) { $verified = "attestation (api)" } } catch { } } if (-not $verified) { # Fall back to the published checksum (integrity only). $expected = (Invoke-WebRequest -Uri "https://github.com/<user>/<repo>/releases/latest/download/<file>.sha256").Content.Trim().Split()[0] if ($digest -eq $expected) { $verified = "checksum" } } if (-not $verified) { throw "verification FAILED — do not run" } Write-Host "verified via: $verified"

Once you manually merge or split something then you will have to manually manage that item forever in terms of merging and splitting. You should be able to get to everything unmerged in the metadata manager. From there you can delete the specific version that you wish.

Have you checked to see if your ISP uses a CGNat?

cgnat?

You can split the versions apart, then delete the one you wish to. Paul

Hi sh0rty can you please this new updated beta. Thanks Update: broader compatibility + more robust status updates Two under-the-hood improvements in this build: Wider Emby Server version compatibility. The previous build was accidentally compiled against an exact Emby Server version, so it would fail to load entirely on any other version. That's now fixed - the plugin should load across a much broader range of Emby Server versions instead of just one specific release. Status updates now use Emby's own metadata provider system. Previously, the plugin used a background timer plus a reactive "fix it if something else overwrites it" approach. It now implements a proper metadata provider that runs as part of Emby's own refresh pipeline (the same mechanism TMDB/TVDB providers use) - so hitting "Identify" or a scheduled library scan now applies the status correctly the first time, in the same pass as everything else, rather than needing a follow-up correction afterward. This should make status updates more reliable and consistent, especially right after a metadata refresh. As always, happy to hear if anyone hits issues on their specific Emby Server version - that's genuinely useful info for a wider beta. EmbyTVShowStatus.dll

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

Probably due to your cgnat right?

Yes this is what it looks like to me. Solution is to fix the language codes in the file. Portuguese Brazil would be pob or pt-br. The language code you have in the file is probably just regular Portuguese pt or por.

Hi, yes we can add a toggle to control the grouping.

hi, can you please show a screenshot of the message that you get? Thanks.