Client options for Hisense 'VIDAA U3.0 AI' TV OS

[sydlexius 297]

As this is a features request subforum, and the devs have already responded (and are thus aware of FR), I'd say that their job is done. I don't have anything to add.

[unisoft 352]

On 30/03/2025 at 16:21, visproduction said:

I don't use this brand.  It's similar to many problems with TV browser apps.

see: https://raspberrytv.net/help/guides-for-tv:guides-for-other-tvs/installing-third-party-apps-on-tvs-with-vidaa-os
You can try to hack through to make the playback work.  One way that may work is to install Kodi and have it running and then see if Emby can find the TV. 

Or give up trying to use HSense limited App options and get a 4K Streaming box like Onn starting at $20.  The TV will start to appear as a 'cast to' option and Emby Android should easily load.

Try using a mobile, tablet or workstation browser to control casting to the TV.

Point is, people don't want extra boxes consuming electricity, being a fire risk with power adapters, especially some of those boxes. A lot like a neat solution of the app being on their TV. Even the Shield is getting old now and doesn't have 4oD app (UK) on it, whereas in my region, the TV would have all familiar app support from streamers and broadcasters.

My LG is great, and is preferred over Apple TV Emby app. If the app is a glorified web wrapper then it should be doable, though certain brands just use slow chipsets etc and they should probably be excluded. Where the specs are OK for CPU/Memory, then a native app would be preferred for me over a separate box.

Not everyone has lots of formats for media. For example, I only use PNG or JPG for images, m4a/m4b and .ts (for DVD mpeg2) and .mp4 (h264 and h265). You can still do lossless even in mp4 using Intra format if so inclined. Sound wise for movies/tv its AAC LC, Dolby Atmos, Dolby Digital Plus, Dolby Digital. I don't use DTS nowadays due to support starting to erode. I use SRT for subtitles outside of the programme file. These formats are usually fine on Smart TV apps. When the TV gets old and unsupported, it gets replaced as I'd want to keep getting security updates.

Edited April 1, 2025 by unisoft

[simonmason 19]

20 hours ago, EZEd said:

No skin off my nose - my TV works just great - just trying to help OP with his particular problem - did you have a suggestion for the OP?

I jumped in because I have a specific use case.  My elderly mother has two Hisense TVs in her house and we wanted to give her access to the home movies and photos.  She has been able to figure out how to navigate the Hisense menus but doubtful will spend time with a Roku or otherwise.  Which is why we didn't go down that route.

[unisoft 352]

Hisense are really big in UK now, because price and they are fairly good in the budget area compared to other makes that are more expensive and not as good picture quality (for the money). Added to the fact that they also one of the first to have FREELY support (free broadcast TV over IP streams instead of aerial), it was a let down when looking at TVs at a price point (up to £450) for other family, because they had Dolby Vision support whereas LG at that price didn't.

[simonmason 19]

1 minute ago, unisoft said:

Hisense are really big in UK now, because price and they are fairly good in the budget area compared to other makes that are more expensive and not as good picture quality (for the money). Added to the fact that they also one of the first to have FREELY support (free broadcast TV over IP streams instead of aerial), it was a let down when looking at TVs at a price point (up to £450) for other family, because they had Dolby Vision support whereas LG at that price didn't.

Confirmed - my mother is in England.

[unisoft 352]

On 01/04/2025 at 16:46, simonmason said:

Confirmed - my mother is in England.

Yeah Hisense is for me, the new cheap end (for family that don't want to spend loads) and replaces traditional cheap LG LCD, as Hisense have Freely IPTV, Dolby Vision/Atmos support and much better screens, and LG or Sony, maybe Panasonic for high end OLED purchases. Samsung a No for me, as they have despicable firmware updates that remove features after purchase, and poor firmware update support over 4+ years (LG still updating mine after nearly 10 years)

Edited April 11, 2025 by unisoft

[wizbowes 4]

Another vote for HiSense support. Would be fantastic to see it. 

[mtulenev 1]

+Another vote for Vidaa support

[teduser 0]

On 11/1/2023 at 3:17 AM, Luke said:

Hi, hopefully in future updates. In the meantime if it has a browser you can use http://app.emby.media

 the smart TV apps are all web based anyway.

Hi, why does the browser app http://app.emby.media ask me for Premier subscription when I choose Play? is there something to set in the server? thanks

 

[GrimReaper 4739]

Browser in TV mode requires active Premiere subscription for Full playback. 

Emby Premiere Feature Matrix

Quote

PC or Mobile Browser

Feature	Free		Premiere
Full Playback	✔		✔
Live TV			✔
TV Mode			✔

 

[teduser 0]

On 3/28/2025 at 8:26 AM, Przemek said:

Hello, any changes in that topic? I want to buy Hisense projector with vidaaOS and will be great to have native emby app.

Regards.

Un altro voto per Emby su Vidaa

[PrincessClevage 175]

++ for Vidaa support

[Fedoreo 1]

Another +1 for an app.

The browser "works", but on my U6NAU model it goes into "pointer mode" and you can't scroll left or right, making it near-unusable.

[unisoft 352]

Any strategic news on Emby being available on VIDAA app store? The app store has nearly all apps, including Plex, but no Emby.

VIDAA is also used on UK Freely TVs (Terrestrial IPTV to eventually replace aerial and DSAT) from Toshiba and other manufacturers so not just HiSense.

Edited July 15, 2025 by unisoft

[unisoft 352]

Todays News:

Hisense promises up to 8 years of Vidaa updates for TVs

https://www.flatpanelshd.com/news.php?subaction=showfull&id=1752649864

Hisense's Vidaa platform currently powers more than 30 million Smart TVs across over 400 brands, including Hisense and Toshiba, according to the company.

[sk_Mike 1]

+1 for the Vidaa app.  I have a Hisense Projector and the  web interface to use Emby is incredibly challenging.  I also have crashes when playing 4k content using the web browser and emby media link. 

[simonmason 19]

Another year and I am just visiting my mother again. Reminded about how nice it would be to run emby on her TVs and show her the family videos.

[aryehof 0]

+1

[staticmotion 4]

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.

[lancot 0]

+1 

[Famicon 0]

please create an app for vidaa

[Jmackay82 40]

is this still being looked into? I see the post started 2019 we are now in 2025, in 6 years there is still no app for vidaa when it is now one of the leading brands of tvs?

[Luke 42077]

1 hour ago, Jmackay82 said:

is this still being looked into? I see the post started 2019 we are now in 2025, in 6 years there is still no app for vidaa when it is now one of the leading brands of tvs?

Unfortunately you can't just build an app for Vidaa and submit. You have to be a Hisense strategic partner. We have filled out the form for this many times and have never gotten any response back. And then within the last year, they've removed that form altogether, and this is their response:

Quote

"our team is proactively reaching out to partners in our priority list. Once this has been finalized, we might enable the web form in the future."

 

[simonmason 19]

Thanks @Luke

[Luke 42077]

So we have tried. At this point I think user feedback is the only thing that will spur them to change.

My guess is they don't want to have an open app store because it will require them to build a whole infrastructure and policies around submissions, the review process, app monetization, etc.