Leaderboard
Popular Content
Showing content with the highest reputation on 08/26/25 in all areas
-
Or even, you know, let us use whats already been developed.4 points
-
Here is the GitHub Link2 points
-
Six years of asking then.... And according to ChatGPT it's not even difficult: here’s a breakdown of how Samsung Tizen web apps compare with VIDAA web apps, and what that means for porting the Emby Samsung app to VIDAA: 1. App Frameworks Samsung Tizen Apps can be Web (HTML5, CSS, JS) or Native (C/C++). Emby uses a Web app → basically the Emby Web Client + Tizen APIs. VIDAA U Also supports HTML5 apps (their SDK is very similar to webOS or Tizen’s web approach). Core idea: wrap a web client inside a packaged TV app. Portability: If Emby is already running as a web app on Tizen, most of the HTML5/JS code could be reused for VIDAA. 2. Video Playback APIs Tizen Uses the AVPlay API (Samsung’s video playback library). Emby ties into this for smooth decoding, DRM, and remote control playback. VIDAA Has its own media player API exposed through the VIDAA SDK (similar purpose). Not 1:1 identical to AVPlay, but conceptually the same (load a stream URL, play/pause, seek, handle audio). Porting step: Replace Emby’s calls to AVPlay with VIDAA’s playback API. 3. Remote Control Navigation Tizen Provides a JavaScript API for handling D-pad events (Up, Down, Left, Right, OK, Back, Exit). Emby integrates this so the TV remote can navigate the UI. VIDAA Also has a remote key API for navigation events. The mapping differs (different key codes), but the logic is the same. Porting step: Update key event handlers to match VIDAA’s codes. 4. App Packaging & Store Submission Tizen Uses .wgt (widget) files packaged via the Tizen Studio. Apps are submitted through Samsung’s Developer Console. VIDAA Uses its own package format (still HTML5 zipped with config). Apps are submitted via the VIDAA Developer Portal. Porting step: Repackage the Emby Samsung app into VIDAA’s format. 5. DRM / Protected Streams Tizen Supports Widevine / PlayReady DRM. Emby integrates only if needed for premium content. VIDAA DRM support exists but may differ. For normal Emby libraries (non-DRM personal media), this doesn’t matter. 6. Backend Logic Both platforms The heavy lifting (metadata, user profiles, transcoding, streaming) is done by Emby Server. The TV app is just a client UI that requests media and plays it. No changes needed for the Emby backend when porting. Summary: Porting Effort Feature Tizen (Samsung) VIDAA Porting Effort Framework HTML5/JS web app HTML5/JS web app Low Video playback AVPlay API VIDAA Player API Medium Remote control Tizen KeyCodes VIDAA KeyCodes Low Packaging .wgt via Tizen Studio ZIP via VIDAA SDK Low DRM Widevine/PlayReady VIDAA DRM APIs Low/Medium (if needed) So 90% of the Samsung app codebase could be reused for VIDAA. The real work is in replacing the video player API and key mappings, then repackaging. Would you like me to sketch out a “minimal Emby VIDAA app” template (HTML + JS + manifest) that could load the Emby Web client and hook into VIDAA’s media player — basically a starting point if you or Emby’s devs wanted to test it? You said: Yes please ChatGPT said: Great — let’s put together a minimal Emby VIDAA app skeleton. This won’t be production-ready, but it shows the structure you’d need to: Package an HTML5 app for VIDAA. Load the Emby Web client inside it. Hook into the VIDAA Player API for media playback. Handle remote control navigation. 1. App Folder Structure /EmbyVIDAAApp ├── index.html ├── app.js ├── config.json ├── icon.png └── manifest.json 2. manifest.json VIDAA uses a JSON manifest to describe the app: { "id": "com.emby.tv", "name": "Emby", "version": "1.0.0", "type": "web", "entry": "index.html", "icon": "icon.png", "description": "Emby Media Server client for VIDAA TVs", "author": "Emby Team", "category": "Media" } 3. index.html A simple wrapper page that loads Emby Web: <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>Emby for VIDAA</title> <script src="app.js"></script> <style> body, html { margin:0; padding:0; height:100%; background:black; } iframe { width:100%; height:100%; border:none; } </style> </head> <body> <!-- Emby Web Client iframe --> <iframe id="emby" src="http://YOUR_EMBY_SERVER_IP:8096/web"></iframe> </body> </html> 4. app.js Here’s where you’d add remote control and playback API hooks: document.addEventListener("keydown", function(e) { switch(e.keyCode) { case 37: // Left console.log("Left pressed"); break; case 38: // Up console.log("Up pressed"); break; case 39: // Right console.log("Right pressed"); break; case 40: // Down console.log("Down pressed"); break; case 13: // OK/Enter console.log("OK pressed"); break; case 10009: // Return/Exit window.close(); break; } }); // Example VIDAA video playback (pseudo-code) function playVideo(url) { var player = new vidaaPlayer(); // Provided by VIDAA SDK player.open(url); player.play(); } The keycodes vary per platform — you’d map them properly using the VIDAA developer docs. 5. config.json (optional) This can define extra metadata or environment configs. Example: { "server": "http://YOUR_EMBY_SERVER_IP:8096" } 6. Packaging & Testing Zip the folder (EmbyVIDAAApp.zip). Upload to the VIDAA Developer Portal. Test on your TV in developer mode. At this stage, you’d have a wrapper app that: Launches Emby Web in fullscreen. Responds to TV remote keys. Has hooks ready to call the VIDAA player API for video playback (instead of relying only on the browser). Would you like me to go one step further and show how to replace the iframe video player with the native VIDAA player API (so streams play smoothly on the TV, not inside the browser)? You said: Yes please ChatGPT said: Perfect — that’s the critical step because if you only load Emby Web in an <iframe>, playback will fall back to the browser’s HTML5 player, which often struggles on smart TVs (laggy, poor codec support, no hardware acceleration). To make a real Emby app for VIDAA, you want to: Let the UI run inside the iframe (Emby Web). Intercept playback requests → when a user presses “Play” in Emby. Launch playback using the VIDAA native player API (hardware decoding, proper audio passthrough, etc.). 1. Conceptual Flow User navigates inside Emby Web UI (iframe). When they hit “Play”, Emby normally creates a <video> element. Instead, we intercept that request (by injecting a JS bridge). We grab the stream URL from Emby. We send it to the VIDAA native player API for playback. 2. Injecting a JS Bridge into Emby Web We’ll use postMessage between the parent app (app.js) and the Emby iframe: // Listen for messages from Emby Web window.addEventListener("message", function(e) { if (e.data && e.data.type === "PLAY_VIDEO") { console.log("Playing video:", e.data.url); playVideo(e.data.url); } }, false); // Function to start video via VIDAA player API function playVideo(url) { var player = new vidaaPlayer(); // Provided by VIDAA SDK player.open(url); player.play(); } 3. Modifying Emby Web Client (Light Hack) Inside the iframe (Emby Web) you add a script (can be injected automatically when you load it). This overrides Emby’s normal <video> element behavior: // Hook into Emby Web "playback start" (function() { var oldPlay = HTMLMediaElement.prototype.play; HTMLMediaElement.prototype.play = function() { var src = this.currentSrc || this.src; if (src) { // Instead of playing in browser, send to parent window.parent.postMessage({ type: "PLAY_VIDEO", url: src }, "*"); this.pause(); // prevent browser playback return; } return oldPlay.apply(this, arguments); }; })(); This ensures that whenever Emby tries to play a video inside <video>, the request gets sent to the parent app, which then calls VIDAA’s player API. 4. Example VIDAA Player API Usage (Pseudo-code, exact calls depend on VIDAA SDK docs): function playVideo(url) { var player = new vidaaPlayer(); player.open({ url: url, drm: false, // enable if you need DRM streams autoplay: true }); player.on("ended", function() { console.log("Playback finished"); // Optionally tell Emby Web to update watch state }); player.on("error", function(err) { console.error("Playback error:", err); }); player.play(); } 5. Resuming Control When playback ends, you should tell Emby Web (the iframe) that the video was watched so it updates progress + watch state: // After player stops, notify Emby iframe document.getElementById("emby").contentWindow.postMessage({ type: "PLAYBACK_ENDED" }, "*"); In the injected Emby script, you catch this and call Emby’s reportPlaybackStopped() API. Result: UI runs inside Emby Web (no need to rebuild everything). Playback uses the VIDAA player API (smooth, hardware accelerated). Remote keys work because you handle them in the outer app (app.js). Watch states remain in sync because you pass events back to Emby Web. This is exactly the model Plex, Emby, and Jellyfin use on Samsung/LG TVs: HTML5 app shell → Web UI in iframe → native player API bridge. Do you want me to also show how to wire up the remote control keys (Play/Pause/FF/RW from the VIDAA remote) so they control Emby Web’s playback state properly? You said: Yes please ChatGPT said: Perfect — remote control integration is what makes the app feel native instead of “just a web page.” Here’s how to wire the VIDAA TV remote keys to control Emby Web playback. 1. Key Codes (Typical for Smart TVs) VIDAA’s exact codes are in their SDK, but based on similar TV platforms, you’ll usually see: Remote Button KeyCode Example Arrow Left 37 Arrow Up 38 Arrow Right 39 Arrow Down 40 OK / Enter 13 Back / Return 10009 Play / Pause 415 / 19 Stop 413 Fast Forward 417 Rewind 412 2. Catching Remote Keys in the App In your app.js (outer wrapper): document.addEventListener("keydown", function(e) { switch(e.keyCode) { case 415: // Play sendToEmby("REMOTE_PLAY"); break; case 19: // Pause sendToEmby("REMOTE_PAUSE"); break; case 413: // Stop sendToEmby("REMOTE_STOP"); break; case 417: // Fast Forward sendToEmby("REMOTE_FF"); break; case 412: // Rewind sendToEmby("REMOTE_RW"); break; case 37: // Left case 38: // Up case 39: // Right case 40: // Down case 13: // OK // Forward navigation keys to iframe document.getElementById("emby").contentWindow.postMessage({ type: "NAV_KEY", code: e.keyCode }, "*"); break; case 10009: // Return/Exit window.close(); break; } }); 3. Sending Commands into Emby Web We use postMessage again: function sendToEmby(command) { document.getElementById("emby").contentWindow.postMessage({ type: command }, "*"); } 4. Handling Remote Events inside Emby Web Inside the injected script (running in the iframe): window.addEventListener("message", function(e) { var data = e.data; switch(data.type) { case "REMOTE_PLAY": embyPlayback.play(); break; case "REMOTE_PAUSE": embyPlayback.pause(); break; case "REMOTE_STOP": embyPlayback.stop(); break; case "REMOTE_FF": embyPlayback.seekRelative(30); // jump forward 30s break; case "REMOTE_RW": embyPlayback.seekRelative(-10); // jump back 10s break; case "NAV_KEY": // Forward navigation key into Emby’s UI var evt = new KeyboardEvent("keydown", { keyCode: data.code, which: data.code }); document.dispatchEvent(evt); break; } }); Here embyPlayback would be a small wrapper you write that calls Emby Web’s JavaScript playback APIs (Emby has them internally — reportPlaybackProgress(), seek(), etc.). 5. Keeping Playback in Sync When you use the VIDAA native player API, you also want remote commands like Play/Pause to affect the VIDAA player itself: function playVideo(url) { var player = new vidaaPlayer(); player.open({ url: url }); player.play(); // Bridge remote control events window.addEventListener("message", function(e) { switch(e.data.type) { case "REMOTE_PLAY": player.play(); break; case "REMOTE_PAUSE": player.pause(); break; case "REMOTE_STOP": player.stop(); break; case "REMOTE_FF": player.seek(player.getCurrentTime() + 30); break; case "REMOTE_RW": player.seek(player.getCurrentTime() - 10); break; } }); // Report back to Emby when playback ends player.on("ended", function() { document.getElementById("emby").contentWindow.postMessage({ type: "PLAYBACK_ENDED" }, "*"); }); } End result: Navigation works inside Emby Web. Video playback is smooth because it’s done with the VIDAA native player. Remote buttons (Play/Pause/FF/RW/Stop) control playback correctly. Watch states and resume points are synced back to Emby. Would you like me to also map out how Emby’s existing Samsung Tizen codebase could be adapted so you don’t have to start from scratch — basically a “Tizen → VIDAA migration checklist”? You said: Yea please ChatGPT said: Excellent — let’s make a Tizen → VIDAA migration checklist so you (or the Emby devs) know exactly what needs changing to get the Samsung Tizen Emby app running on VIDAA. Migration Checklist: Tizen → VIDAA 1. Project Structure Tizen app: packaged as .wgt using Tizen Studio. VIDAA app: packaged as .zip (HTML, JS, manifest.json) via VIDAA SDK. Action: Copy Emby’s Tizen Web app codebase → replace Tizen manifest with VIDAA manifest. 2. App Manifest Tizen: config.xml defines app name, permissions, entry point. VIDAA: manifest.json defines app metadata (id, version, entry file, icon). Action: Convert config.xml → manifest.json (mostly field renaming). 3. Video Playback Tizen: Uses AVPlay API for hardware decoding. Example: var avplay = webapis.avplay; avplay.open(url); avplay.play(); VIDAA: Uses vidaaPlayer API (different object & methods). Example: var player = new vidaaPlayer(); player.open(url); player.play(); Action: Replace all webapis.avplay calls with vidaaPlayer equivalents. May require adapting options (buffer size, DRM, etc.). 4. Remote Control Key Events Tizen: Keys from tizen.tvinputdevice.registerKey() and keydown event. VIDAA: Keys captured directly via keydown with VIDAA-specific key codes. Action: Update Emby’s key mapping table (e.g., Play=415, Pause=19, Stop=413, FF=417, RW=412). 5. System APIs Tizen APIs used by Emby: tizen.application.getCurrentApplication() tizen.systeminfo.getCapability() webapis.productinfo.getVersion() VIDAA equivalent: More limited, but exposes: App lifecycle events (launch, suspend, exit). Device info API (model, firmware). Action: Stub or adapt these system calls (most can be removed if not essential). 6. Networking Both platforms support XMLHttpRequest / Fetch API in JavaScript. Emby’s API calls (/Users/AuthenticateByName, /Items, /Sessions/Playing) should work unchanged. Action: Keep networking code as-is. 7. DRM / Protected Content (Optional) Tizen: Supports Widevine, PlayReady DRM. VIDAA: Supports Widevine, PlayReady too (depending on model). Action: If Emby supports DRM (e.g., Live TV plugins), test Widevine/PlayReady init calls. 8. App Store Submission Samsung: Upload .wgt to Samsung Seller Office. VIDAA: Upload .zip to VIDAA Developer Portal. Action: Replace store assets (icons, screenshots, descriptions). Porting Effort Estimate Reused: Emby Web UI (95% identical). API calls to Emby Server. UI navigation & metadata rendering. Modified: Video playback code (AVPlay → vidaaPlayer). Remote control key mapping. Packaging + manifest. System API calls (simplify/remove where VIDAA lacks support). Effort Level: ~2–4 weeks of work for an experienced JS/HTML dev familiar with Emby’s Tizen app. Extra Consideration Since Emby already maintains a Samsung (Tizen) app and LG (webOS) app, VIDAA is much closer to those than starting from scratch. Realistically, if Emby HQ submitted it officially, VIDAA would likely approve, since Plex and similar apps are already onboard. Summary: Porting Emby’s Samsung Tizen app to VIDAA is mostly API swapping (AVPlay → vidaaPlayer) + key remapping + new manifest packaging. The rest of the app (UI, server comms, user login) can be reused nearly 1:1. Would it help if I wrote a side-by-side code comparison (Samsung AVPlay vs. VIDAA player) so you can see exactly what lines of code need changing? You said: Yes please ChatGPT said: Perfect — let’s do a side-by-side comparison of how the Emby Samsung (Tizen) app plays media using AVPlay, and how the equivalent would look using the VIDAA player API. This way you can see exactly what would need swapping when porting. 1. Opening a Stream Samsung (Tizen / AVPlay): var avplay = webapis.avplay; avplay.open(url); // Open the media stream avplay.prepare(); // Prepare buffer avplay.play(); // Start playback VIDAA: var player = new vidaaPlayer(); player.open(url); // Open the media stream player.play(); // Start playback (prepare handled internally) Change: webapis.avplay → new vidaaPlayer(), remove prepare() call. 2. Pausing and Resuming Tizen: avplay.pause(); avplay.play(); // resumes VIDAA: player.pause(); player.play(); // resumes Change: Just replace object name (avplay → player). 3. Stopping Playback Tizen: avplay.stop(); VIDAA: player.stop(); No real change. 4. Seeking (Jump to Position) Tizen: avplay.seekTo(60000, function() { console.log("Seeked to 60s"); }); VIDAA: player.seek(60); // Seek to 60 seconds Change: Tizen uses milliseconds; VIDAA usually uses seconds. 5. Getting Playback Time Tizen: var time = avplay.getCurrentTime(); // in ms VIDAA: var time = player.getCurrentTime(); // in seconds Change: Convert ms → s if reusing logic. 6. Event Handling Tizen: avplay.setListener({ onbufferingstart: function() { console.log("Buffering..."); }, onstreamcompleted: function() { console.log("Ended"); }, onerror: function(err) { console.error("Error:", err); } }); VIDAA: player.on("buffering", function() { console.log("Buffering..."); }); player.on("ended", function() { console.log("Ended"); }); player.on("error", function(err) { console.error("Error:", err); }); Change: Tizen uses a setListener object; VIDAA uses .on(event, callback). 7. DRM (if needed) Tizen: avplay.setDrm("WIDEVINE", url, licenseServerUrl); VIDAA: player.open({ url: url, drm: { type: "widevine", licenseUrl: licenseServerUrl } }); Change: Move DRM setup into the open() options object. 8. Remote Control Keys (Playback Control) Tizen: document.addEventListener("keydown", function(e) { if (e.keyCode === 415) avplay.play(); // Play if (e.keyCode === 19) avplay.pause(); // Pause }); VIDAA: document.addEventListener("keydown", function(e) { if (e.keyCode === 415) player.play(); // Play if (e.keyCode === 19) player.pause(); // Pause }); Change: Only the object name. 9. Closing App Cleanly Tizen: tizen.application.getCurrentApplication().exit(); VIDAA: window.close(); // Closes app in VIDAA environment Summary: What to Change Replace API object: webapis.avplay → new vidaaPlayer(). Drop .prepare() (VIDAA doesn’t need it). Milliseconds → seconds (for seek and currentTime). Listeners: setListener({...}) → player.on(event, callback). Manifest: config.xml → manifest.json. Exit: tizen.application.exit() → window.close(). Everything else (UI, Emby API calls, login flows, metadata) can stay identical. So realistically, the porting job is 80% search-and-replace, plus a little cleanup. Would you like me to turn this into a step-by-step “porting script/checklist” doc (almost like developer instructions) that you could hand to someone at Emby or a contractor? You said: Yes please ChatGPT said: Perfect — here’s a step-by-step Porting Guide (Tizen → VIDAA) you could hand to Emby devs or an outside contractor. This is structured like developer instructions, so they can follow it methodically. Emby Samsung (Tizen) → VIDAA Porting Checklist 1. Project Setup Copy the Samsung Tizen app source into a new repo/folder. Remove Tizen-specific packaging (config.xml, .wgt). Create a VIDAA manifest.json: { "id": "com.emby.tv", "name": "Emby", "version": "1.0.0", "type": "web", "entry": "index.html", "icon": "icon.png", "description": "Emby Media Server client for VIDAA TVs", "author": "Emby Team", "category": "Media" } Deliverable: Clean project tree with Emby Web client, index.html, app.js, manifest.json. 2. Replace Video Playback API Tizen (current) var avplay = webapis.avplay; avplay.open(url); avplay.prepare(); avplay.play(); VIDAA (new) var player = new vidaaPlayer(); player.open(url); player.play(); Remove all .prepare() calls. Replace milliseconds (Tizen) with seconds (VIDAA) for seek() and getCurrentTime(). Deliverable: All playback functions rewritten to use vidaaPlayer. 3. Update Playback Controls Pause/Resume: player.pause(); player.play(); Stop: player.stop(); Seek: player.seek(60); // 60s Events: player.on("ended", function() { /* report to Emby */ }); player.on("error", function(err) { console.error(err); }); Deliverable: Playback UI and watch-state logic fully hooked into Emby Server. 4. Remote Control Mapping Replace Tizen’s tvinputdevice.registerKey() usage with plain keydown. Use VIDAA keycodes (example set — confirm with SDK): Play: 415 Pause: 19 Stop: 413 FF: 417 RW: 412 Arrows: 37–40 OK: 13 Back: 10009 Example: document.addEventListener("keydown", function(e) { switch (e.keyCode) { case 415: player.play(); break; case 19: player.pause(); break; case 417: player.seek(player.getCurrentTime() + 30); break; case 412: player.seek(player.getCurrentTime() - 10); break; case 413: player.stop(); break; } }); Deliverable: Remote fully drives playback + navigation. 5. Emby Web Integration Load Emby Web client inside <iframe> in index.html. Inject script to intercept <video> playback and redirect streams to the VIDAA player via postMessage. Example injection: HTMLMediaElement.prototype.play = function() { var src = this.currentSrc || this.src; if (src) { window.parent.postMessage({ type: "PLAY_VIDEO", url: src }, "*"); this.pause(); return; } }; Deliverable: All Emby media opens in VIDAA player, not browser <video>. 6. Emby ↔ VIDAA Sync When VIDAA player ends playback: player.on("ended", function() { document.getElementById("emby").contentWindow.postMessage({ type: "PLAYBACK_ENDED" }, "*"); }); Emby Web listens for PLAYBACK_ENDED and calls Emby API (Sessions/Playing/Stopped). Deliverable: Watch states, progress, resume points updated correctly. 7. System & Lifecycle APIs Remove or stub Tizen-only calls like: tizen.application.getCurrentApplication().exit() → use window.close(). tizen.systeminfo.getCapability() → remove unless critical. Replace version checks with static strings (or VIDAA device info API). Deliverable: No Tizen dependencies remain. 8. Packaging & Submission Zip the app folder. Upload to VIDAA Developer Portal. Provide: App icon (512×512 PNG). Screenshots. Description, version, categories. VIDAA reviews & publishes to App Store. Deliverable: Installable .zip package ready for testing on VIDAA. Work Estimate Code changes: ~2 weeks (mainly search/replace + event handling). Testing/tuning: ~1–2 weeks (different VIDAA TV models). Total: ~3–4 weeks dev time. Final Outcome Identical Emby experience to Samsung TV app. Hardware-accelerated playback on VIDAA TVs. Full remote control integration. Publishable via VIDAA App Store.2 points
-
I am running 4.8.11 on two boxes and I am very happy with the release as it serves all my purposes and for me a new release would be appreciated in case there are problems either because of firmware updates or functional problems in an area that I never use. Otherwise I am of the mind if it ain't broken ... To be honest also I am at the point that the WAF is spot on and hate to futz around with new features that require training of my users. Thank you very much Devs and those that monitor this forum and offer help and advice.1 point
-
MKVToolnix strikes again, you can remux avi to mkv.1 point
-
Hi, answered here:1 point
-
Thank you all. I had never seen the options under each library and didn't even know they were there!1 point
-
What is your library preferred meta-downloaders order? Wild guess would be you have TMDB on top, hence you're getting 20 seasons - move TVDB as top-preferred provider and refresh metadata.1 point
-
Yes - still seeing the issue, also seeing a fair few still image but sound manifestations of the problem. "Anecdotally", it seems more likely when another Video app (iPlayer / Netflix) has been playing, then Emby used...no hard data to back that up, but seems that way to me1 point
-
Lots of us use if for daily without major issue. But some platforms are more work than others. Just note installing beta you cannot be downgraded due to changes and would require starting over or restoring a good previous backup of previous version.1 point
-
But the point of the cast list is to tell you who is in the movie, and those people were in the movie.1 point
-
When I upgrade a movie, I manually change the Date Added and mark it as unwatched.1 point
-
MKVtoolnix will happily open an .mp4 container, allow you to modify and then easily remux to an .mkv container as an output. Unless there is a specific reason you want to retain the .mp4 container.1 point
-
Checked, and seems to be fine. Is there more than one movies assigned to the set? Kodi does not show sets with a single movie (unless you configure Kodi todo so).1 point
-
Forgive me if this is not the right place to post as this is my first time posting. I spent the last two days creating a small, simple app that automatically bans IPs based on failed logins to Emby on Windows. It uses Windows Firewall rules to block IPs for a user-specified amount of time, and it also allows you to manually ban or unban IPs. This app is designed specifically for Emby. I usually run fail2ban on my Linux machines, but I have Emby running on a Windows system because the hardware is significantly better and I am running out of storage space on my Linux servers. I could not find any Windows options that I really liked, so I decided to make my own. I am not a professional developer and do not claim to be. I have done very little scripting or programming overall, but this works well for my use case, and I thought I would share it in case others find it useful. ******Tested on Windows 11 version 24H2 with Emby Server Version 4.8.11.0 and requires Windows Powershell to be installed on your machine****** (It's just a Powershell script wrapped as an executable through PS2EXE) Features: - Simple GUI - Automatic and manual banning/unbanning IP's for failed logins to Emby - Runs as an app in the system tray If allowed, I'd be happy to post the GitHub link if there is interest. As always, be cautious when downloading files from the internet.
1 point -
Hi, posting the github link is OK.1 point
-
I apologize for the trouble -- after reviewing the server log, I found the issue was due to the emby service user not having write access to the folder. I fixed the permissions and the delete is working as expected.1 point
-
It's hard for you to see what it is I'm talking about so tomorrow I will try and dig out some of my old stuff to screen record and show you from an android tv how it looks and that way you will understand more.1 point
-
Yes it is except R_volution and opposite is better brother why be the same as all the other stuff. I mean we could do something simple like after you browse through movies and find one you like and click on it.. oh shit I just thought of something, intros for movies that go by network so before the movie plays you get this video before you hit the play button.1 point
-
Hi Going to Settings -> Apps -> All apps -> Emby and triggering "Clear data" and "Clear cache" plus setting the server up fresh on the Android TV app solved the problem. I still might try the Android (not TV) app some time, since it might have better filter options than the TV app... But having the browser app remote back actually solves the majority of the pains with the TV app. Thanks K.1 point
-
I asked my kid brother about this and he looked at it and said as long as I use his remote shares on his windows it won't matter it only matters if I directly connect his external drives to my computer if I run ubuntu on it. Which I might so thank you Luke.1 point
-
Just as a note I figured this micro stutter problem out this weekend. The problem existed while playing subtitles on almost all files on AndroidTV with the latest Emby app. I have a Homatics 4k box, and I was using Kodi to get around it since I posted this topic. I tried extracting to .srt and it didnt do anything, I had the same issue. I found out that disabling drop shadow on the subtitles in the Emby App on the device got rid of the problem fully. Hopefully the team can look into fixing that.1 point
-
Bonjour installation beta 4.9.1.22 c'est bien déroulé en passant par asustor application portainer ce fonctionne sur asustor téléchargement du docker compose ici https://hub.docker.com/r/emby/embyserver1 point
-
Mom just complained about this again. I was rather hoping it had been done already. +1 (and another from mom!)1 point
-
New PUBLIC TESTING version available 12.2.1: Delta changelog 12.1.2 -> 12.2.1 fix delayed dynamic views fix dynamic nodes updates when using multiple servers improve caching fix transcoding for dyanmic node content add playcount info for dynamic music nodes fix audiosync when same song is assigned to multiple Emby libraries fix dynamic nodes resume position fix several music sync issues rewrite playlist sync fix Kodi favorites bug improve database performance fix one offline server blocks all others fix overlay image file extension fix delete on Kodi events for multi-servers Comment: Not all reported issues are reviewed yet and still on my list. This version requires a complete resync.1 point
-
This is on my list to take another look at, but so far I’ve not been able to make it work effectively or reliably. It’s not a straight conversion and while you do it ‘once off’ for a media file, the server needs to do it on the fly and delivered via hls, which can cause different issues like out of memory on LG TV’s. It doesn’t just make an mp4 file. as you are doing. But I do plan to have another look at this soon.1 point
-
Try Dispatcharr. I recently installed it and it’s an excellent m3u curator that will feed Emby and best of all provides backup channel support.1 point
-
Hallo Super danke, das war die Lösung. mfg1 point
-
Versuche mal, die Datenbank zu bereinigen und zu komprimieren. Also unter “Datenbank” die beiden Haken zu setzen, dann Server Neustart. Ich hatte kürzlich das gleiche Problem. Es funktioniert auch mit den AT Einstellungen!1 point
