Windows Media Center Returns!

[Pinpoint]

I had a short chat with acer-.. and I guess it was your blog that I had read on the subject? So well - nice to meet you!

Indeed, it's me. Nice to meet you too

Yes, TVnext beats those timings - with HLS streaming to a LAN client included. It's very close to a TV's hardware tuner switching (just 100-300ms slower).

It's a bit difficult to name absolute times because it depends on whether the tuner needs to re-tune or the target channel is on the same transponder/mux and also on whether you are hitting a video keyframe or you just missed one.
Without transcoding, 700ms are achievable, when the tuner is on Linux. Unfortunately there's a 300ms penalty on Windows with BDA (comparing same tuners). Transcoding adds 600-900ms.

Sounds very promising! (FWIW, I briefly tried Emby a while ago - before it moved to a closed-source license I believe - and switching times were definitely not that fast )

TVnext just pipes the stream into ffmpeg in and out, so there's buffering and overlapping disk IO in the way. That's probably why your values are higher.

Ah yeah, I should have been clearer about that: in our tests, piping was used too without first writing the content to the disk (I updated my post to include the timings I get without ffmpeg in the mix: less than a second/1 second max, so ffmpeg doing "nothing" basically adds 0.5s/1s: not free, but certainly not slow either).

Thanks a lot for pointing this out, I wasn't aware. It should be fixed now.

My pleasure

The WMC UI Beta is available now: http://WMC.emby.media/

There's also a new video with a detailed walkthrough: https://youtu.be/dbbZhED1z94

Great video!

Quick question: I don't have an Emby server set up so I couldn't give it a try, but I took a look at the package files and noticed that while the .NET Framework app itself was not obfuscated, many .js files in the Electron app were (and the Electron part seems to be where most of the fun happens: AFAICT, the .NET app only deals with networking and plugin installation/update). What are your plans regarding customization?

[softworkz]

Sounds very promising! (FWIW, I briefly tried Emby a while ago - before it moved to a closed-source license I believe - and switching times were definitely not that fast )

Yea, that's correct and it's still the same in current Emby Server (without TVnext). I use to explain it like this:

Emby is very good in playing back ANY kind of media on ANY kind of device while employing the available and configured ways of of hardware-accelerated or sw-transcoding at the server (disclaimer: I developed most of this and I'm also contributing to ffmpeg in this area).
These procedures are reliable and universal, and as such they also work for TV streams, but a typical downside of universal solutions is that they often can't provide optimal handling for specific use cases. That's where TVnext comes into play: it provides optimized, no-compromise processing for TV streams only. It processes and decodes MPEGTS streams in-memory, it parses video streams to identify IDR frames and creates HLS segments on-the-fly, streaming them to clients even before they are written to disk and before they are complete. None of this would be possible with ffmpeg.

Ah yeah, I should have been clearer about that: in our tests, piping was used too without first writing the content to the disk (I updated my post to include the timings I get without ffmpeg in the mix: less than a second/1 second max, so ffmpeg doing "nothing" basically adds 0.5s/1s: not free, but certainly not slow either).

LOL, granted - it's a matter of perspective: If you would have been spending so much time on fighting down every 100ms, you would probably consider it slow as well

Great video!

Quick question: I don't have an Emby server set up so I couldn't give it a try, but I took a look at the package files and noticed that while the .NET Framework app itself was not obfuscated, many .js files in the Electron app were (and the Electron part seems to be where most of the fun happens: AFAICT, the .NET app only deals with networking and plugin installation/update). What are your plans regarding customization?

We never had such extreme obfuscation before and the other apps don't have it yet, but we've gotten challenged by Chinese cracks for circumventing Emby Premiere limitations (even though it's just $6/month for multiple servers and 25 clients).
The regular Emby Theater app is loading the application files from an online source, but for the Emby Theater WMC, they are part of the installation and even more exposed. It's also a test for whether we'll proceed with this.

It doesn't affect customization options. The available options are:

- Server Plugins
These are very powerful and allow customization in really broad range of areas
Server plugins can add configuration pages for server administration, but don't change client UI
- Web App CSS
For the web app which is hosted by Emby Server directly, you can configure custom CSS
- Entry Page Customization
There are some options for configuring text and logo for the entry/login pages
- Context Menu Customization
This is an upcoming feature which allows to add client-side functionality in form of adding context menu items (or extra actions in case of the WMC UI)

Customization by making modifications to the htmljs code directly is not supported. But this has nothing to do with the obfuscation. Even when you had the original code to modify it, you wouldn't have any fun doing so, because this code is so rapidly changing in fundamental parts, that it would just drive you to desperation while trying to keep-up (and I know what I'm talking about, sighh).

[softworkz]

Sounds very promising! (FWIW, I briefly tried Emby a while ago - before it moved to a closed-source license I believe

A note on the subject of Emby going closed-source: This is seen by many as a bad and unfriendly move, but only few people really understand the background. Even though all of the Emby code has been provided under an open-source license, it has never really been a typical open-source project developed as a community effort. In fact, 98% of the Emby code had been developed by just 2 persons (the Emby owners). If it would have been different, it wouldn't have been possible to go closed source (after replacing the 2% with own code).

One of the main actors behind the JellyFin fork had earlier published a crack to circumvent the "Emby Supporter" mechanism which provided some extra features, and also made inacceptable claims and statements, which finally led to the decision of closing the source and revoking the GPL licensing. From a legal point of view, the fork couldn't be disputed, but from a moral standpoint, it was just stealing.
While they made progress in certain areas, they still have more code from the old Emby 3.x (when they forked) than current Emby itself.

Without these events having happened, Emby might possibly still be open source these days (even though under a different license). But when you see people standing up in front of you, telling what rights they think they have on the code on which you have been working on for years, and to which they didn't contribute the slightest bit, then you can't just tolerate that. At that time, I've been the first one to suggest going closed source, which was the best possible decision.
What I really hate to see these days is that so many people are thinking that JF would be the "good guys" and Emby the bad guys.
Though, nothing against all the community developers participating and contributing there. Probably they don't even know that the original code base was effectively stolen.