All Activity

I am moving some code from JS that currently runs inside a js page. The current code is var serverId = "...."; // a valid server Id var imageid = "....."; // a valid image id var imageUrl = ApiClient.getImageUrl( imageId, { type: "Primary", quality: 90 } ) return "<<a is="emby-linkbutton" href="/item?id=` + imageId + `&serverId=` + serverId + `"><img src="` + imageUrl + `" height="200px" alt="` + v.Name + `" /></a>`; I am trying to get the same exact url from C# function calls. I have access to all the globals created during the service construction. Thanks in advance Scott

ahh thanks @ebrthat's probably behind it

So the topic is dead, and I am still having many playback issues.

Ended up writing two scripts () : one to recursively go through TV show root/letter subfolders/series folders and copy series thumb as each <episodefilename>-landscape image, another one to import all those landscapes as episode thumbs through API endpoint. It was a bit of a chore. But served the purpose.

If you really want these things, you are better off to move to Android or use InFuse.

So when will the next update be? I am happy that this is finally hitting crApple TV. Another step closer to it being a viable alternative to the new POS Scamazon "Fire" sticks.

New build up (1.0.0.39) - it covers a couple of things from both of you. @GrimEvil - your log pinned it exactly. When you launch a game from the native Emby app, it opens your phone's browser fresh, with no Emby login, so the game couldn't authenticate to pull the ROM - that's the "network error." Fixed in 1.0.0.39: if the player opens without a login, it now shows a quick Emby sign-in and remembers it on that device. Use the "Play Game (App)" link on your phone (the "Browser" one is for when you're already in a web browser, which is why it just closes in the app). Two notes: - On mobile data (5G) it should now work end to end. On home WiFi that "App" link points at your external domain, which your network doesn't resolve internally - that's a DNS thing on the network side (split-horizon DNS, or just use Emby in your phone's browser there). - Android TV: no way around this one, sorry. ROMote plays in a browser, and the Android TV app has no browser to open, so it's really a desktop/laptop/phone/tablet thing. @EmreWest - on the duplicate remover: it's not just picking the first US file, it scores each copy. A proper release beats beta/proto/bad dumps, then it ranks by region (USA/English first, then Japan, then everything else), then prefers the newest revision. So US usually wins because it's ranked highest, not because of folder order. A "preferred region" option so you could rank, say, Europe first is a good idea - I'll look at adding it. And the iPhone Safari zoom-on-fast-taps you mentioned was a real bug, also fixed in 1.0.0.39. It's an iOS Safari quirk (it ignores the no-zoom setting), now suppressed. Build is attached - thanks both, this kind of feedback is exactly what I need. ROMote.dll

@LukeI can't, if I run into the issue again I will update this thread.

I do wish you would make it easier to search. The long stream of alphabet is a real pain and VERY out of date.

I've done a bit more checking, and what I've found is this: If you type a number in, then pause before entering the next, there is a 2.5-second delay before it is hidden. If you type the PIN incorrectly, there is a 3-second delay before all the numbers are hidden (as they are hidden one at a time in sequence.) This means that even if you're quick your PIN is still visible. My friend can't type as quickly as I can, due to her disability. Her PIN is easily read while she's entering it. On the Samsung TV app, no numbers appear in the boxes on-screen at all.

Read Luke's reply to that thread.

Question, I happen to be inside a JS function when I need this. The way that I solved it, is to use var url = ApiClient.getUrl("/emby/System/Configuration"); ApiClient.getJSON(url).then(response => { if (response.EnableDebugLevelLogging) { ....... Is there a better way?

Thanks!

In my experience with the Android app searching, it is far longer than 15-20 seconds, it can be up to like 3 minutes +/-, however, as I said before, same search terms work perfectly fine on web UI, and I don't use search a lot especially from the web UI because I'm mainly using Android clients, So I don't know if there's some magic combination that would cause it to happen on the web UI as well, and if it does happen, is it the same 3 minutes, or is it shorter.

Well, when you put it that way...:D

The absence of a checkmark on a TV Series poster tells you it is fully watched (at least the content you actually have). While you can potentially make an argument that that is inconsistent, it actually fits the usage pattern for most people. With movies, you want to see what has already been watched (or not) but with Series, your are more interested in if there is any new content to watch. This is because movies are (typically) watched once or, at least, the status is binary while with a Series, it can be constantly changing day to day as new content comes in.

I think the search is massively improved however there are still occasionally a few search queries that timeout. I think an important part of this problem is how the server locks up during search. Even with the vast majority of successful searches, it's still 15-20 seconds of server downtime anytime a user does a search (I can't even get the dashboard to load). Is that something we can have looked into? Should that merit its own discussion thread?

Not to mention it is just plain stealing.

Yes @ebrthis has to be one of the new VegaOS pieces of garbage.

For Premiere features, you can't! All servers and clients need access to mb3admin.com for Premiere features; non-Premiere features will work fine without. https://emby.freshdesk.com/support/solutions/articles/44001173099-emby-premiere-feature-matrix

I understand the frustration of not seeing a requested feature making it's way into Emby. Heck, I've got one or two that are years old too. - HOWEVER - Just for shits & giggles, I thought I would make something that would handle one of my requests; Actor, Cast, & Crew management. I didn't think it would be that hard since I handle relatively large datasets all the time. I have since discovered that there are many moving parts. So, so many moving parts. I've had 32 commits to git in just 12 days because I keep having to fix crap that I didn't consider. Touch one thing and it affects 10 others. A simple fat-finger keystroke can be catastrophic to a media library. And if you think people get frustrated with missing features, just wait until they have a function that deletes or corrupts their media database. And I am only dealing with 56K videos on a single dedicated machine and extremely clean and organized library (if I do say so myself). They have to consider not only their own testing library, but the millions of files and untold number of configurations out in the wild. Emby's developers have to walk a very fine line. If Jellyfin rolled out a feature that was alpha quality and it caused issues, you can chalk it up to being open source testing level software that you are not paying for and you would forgive them because it's a small development team. Emby would have people yelling that they paid them good money and they ruined everything and they are the cause of their wife leaving with the kids and the dog biting them. Emby is not like Plex where they have a large development and support structure. If Plex did something like that, everyone would be justified for getting their torches and pitchforks. So while I understand and even empathize with many people frustrated with the snail like pace of often requested features, I now have a newfound understanding of why these things might take this long. I should probably add a disclaimer. I am not a part of the Emby team, I don't know any of them personally, and I don't presume to speak for any of them. The opinions expressed in this post are mine and mine alone. I don't want to step on any toes and I don't want anyone lashing out at the forum mods because they think I am a shill.

Thanks for confirming. Embedding artwork in all files would add ~33GB to my music ssd, which i dont have right now, but maybe thats the only way to go. I had created a feature request, so will see if others in community have any interest in an embedding option, if its just me it might be time for me to upgrade my ssd! Maybe a feature request for a surface for plugin developers would bemore realistic.

Hi, there is no way to do this. Why wouldn't the files just have it embedded to begin with?

Have you been migrated to CGNAT?