Emby Live TV needs work? Or is it me?

[Armageus 67]

10 hours ago, cayars said:

So "Is this still coming anytime soon?"
I could say it's already happening piece by piece, just differently.

The "Major" TV Changes have been coming forever - is there any danger of anything actually being released this year though?

Even minor feature updates seem to have dried up, with the last "stable" release 7 months ago (and no jumping on the Beta and enduring the weekly regressions isn't an acceptable option, especially given that it doesn't even have any stand out features - mostly just a collection of tiny bug fixes)

[pwhodges 1527]

3 minutes ago, Armageus said:

it doesn't even have any stand out features

Not everyone would agree with this.  Think HDR tone-mapping, for instance.

But with regard to Live TV, what I'm eager for is native access to Hauppauge tuners.

Paul

Edited May 2, 2022 by pwhodges

[Armageus 67]

1 hour ago, pwhodges said:

Not everyone would agree with this.  Think HDR tone-mapping, for instance.

Sorry, but I must be in the minority due to not downloading illegal 4K rips and needing to tone-map them

[emveepee 112]

13 hours ago, cayars said:

... framework has essentially turned other systems into "tuners" that give Emby access to additional channels without additional baggage.

I hardly call removing the two way interface with TV plugins  making all systems effectively Emby-only "baggage".  I understand why it was done, these interfaces needed to be improved or significantly modified to move forward, and the decision was to remove them.  To a very few users 4.7 will actually be a step backward so definitely not "perfect" either.

Martin

[Carlo 4330]

8 hours ago, Armageus said:

Even minor feature updates seem to have dried up, with the last "stable" release 7 months ago (and no jumping on the Beta and enduring the weekly regressions isn't an acceptable option, especially given that it doesn't even have any stand out features - mostly just a collection of tiny bug fixes)

Nothing has dried up. We're getting a stead set of new features and improvements in the current beta which is rock solid.

8 hours ago, pwhodges said:

Not everyone would agree with this.  Think HDR tone-mapping, for instance.

But with regard to Live TV, what I'm eager for is native access to Hauppauge tuners.

Paul

Native support on many OS for Hauppauge is surely going to be a hit.
Personally I'm more excited for the HDHomeRun faster tuning and ability to share Mux for OTA.  In my area the 4 Muxes I would use most give me 12 channels which also happen to be what would be used most of the time (90%+ I'd guess).  With a tuner already locked to a Mux it's near instant tuning.

6 hours ago, Armageus said:

Sorry, but I must be in the minority due to not downloading illegal 4K rips and needing to tone-map them

Not sure how you conflate 4K rips to being illegally downloaded.  I think if you were to look at different threads, you would see that many of us do our own Rips from content we purchase and then optionally post process the content. Same with tone-mapping which has nothing to do will illegal activity.

5 hours ago, emveepee said:

I hardly call removing the two way interface with TV plugins  making all systems effectively Emby-only "baggage".  I understand why it was done, these interfaces needed to be improved or significantly modified to move forward, and the decision was to remove them.  To a very few users 4.7 will actually be a step backward so definitely not "perfect" either.

Martin

That's a strange way to look at it IMHO. Previously Emby Server had to have unique handling for different plugins since they all worked differently and worse yet had unique "personalities" that often needed special handling. The new format streamlines and cleans up the way plugins are consumed.  Emby no longer needs to handle a NextPVR recording differently then a TVHeadend recording which is different from a native Emby Recording.  Same with guide data which as you know may or may not be fully intact.  The responsibility for all of this is now shifted to Emby Server where all guide, scheduling, recording is consistent and done in the same manner regardless of source of content.

That makes every work the same and more importantly the way the user would expect things to work. Previously users often ended up fighting the system trying to clear channels for example as all tuners were removed they could see and they refreshed guide data which clears channels no longer present.  Works great unless you were using a plugin which imported channels differently and rendered the user's actions meaningless. The user had to know to remove the plugin and then refresh the guide to clear things. Little things like that go away as no special handling is needed moving forward.

Using the new framework the responsibility of the plugin is shifted so it only has to give Emby a list of channels info when requested and of course to tune a channel when requested. That greatly simplifies the plugin framework for 3rd party developers as they have far less to do now. A TV plugin can still optionally provide guide data if it wants to but Emby doesn't need to know about this. The plugin writes to disk a standard XML file on a schedule and the user adds it as a guide source.  This has been supported for a long time as it's the counterpart to m3u files. Existing functionality like that can now be leveraged without the Server knowing or caring about the guide source.

It's a completely cleaner framework that simplifies the way Live TV works without the crazy variations it previously had to deal with.
Possible downsides short term is the need to re-setup the plugin by users but it's a one-time conversion/setup.

Granted there are a couple minor downsides that apply to maybe 2 plugins but mostly NextPVR since it was likely the most advanced plugin.  It does remove NextPVR's scheduling logic which arguably is better than Emby's at present depending on overall configuration. I can't really think of other downsides that might be short term but I can see how this will greatly simplify additional functionality to be added that would have been a real choir previously.

This really is a needed transition that will open the door to more advanced functionality additions. I think it goes without saying the cleaner the framework the easier it can be to use as well as having far less chance for issues/bug to appear.  It will surely make testing a whole lot easier for sure.

Without the crazy variations that previously existed, features such as combining channels (ABC, CBS, NBS, FOX, PBS, etc) from multiple tuner sources with priority ordering become achievable for better guide and channel presentation. It could allow "duplicate m3u channels" to become stacked instead of dupes dropped for spare channels when an m3u stream doesn't work.  These things might sound like small things but set the stage for much more advanced functionality that previously would not be possible like advanced DVR scheduling.

 

[emveepee 112]

22 minutes ago, cayars said:

I can't really think of other downsides that might be short term but I can see how this will greatly simplify additional functionality to be added that would have been a real choir previously.

As I said if you buy in to 100% Emby infrastructure it is a strong move forward.  If you want to use Kodi or other NextPVR clients you won't be able to, since there will be conflicts. Also it is not just scheduling it is recordings, since these will be completely isolated from each other. 

For example I've never used an Emby client for Live TV on an RPi which I think right now that is strongly a Kodi PVR market running LibreElec and OSMC.  How is Emby Theater working on the RPi w.r.t. a STB experience for broadcast media,  comskip etc.

Martin

[Carlo 4330]

Live TV presently plays great through Emby Server beta using Kodi. I have this installed on a couple laptops and it's working great for me.

I just got into the Pi scene right before Christmas and now have 6 of them. One has Windows (Arm 64) installed. I can playback Live TV via Chromium on the Pi but most channels require transcoding as the video drivers still need work. If we had a Theater for Arm Windows build, I would try that but still think better video drivers are needed.

I have tried Theater for Linux Debian build on Raspbian Pi, Debian Buster, Debian Bullseye, Ubuntu & DietPi in 32 and 64 builds. The 64 bit version IMHO runs a little smoother using less resources with my favorite being 64 bit DietPi OS. I'm running that for container use in ProxMox as well and have my main Emby server presently using it. I've also tested Kodi I believe on the same OSes in both 32 and 64 bit and this too works ok for me.

I've not installed LibreElec or OSMC on any Pi so I have no clue how that would work. Just thinking about the changes Luke has/is making can only help these devices IMHO as it allows more consistent streams with the same handling vs the previous variations. All 6 of my Pis are the same model and configured the same. It's the high end 4B with higher clock rate and 8GB memory. Each is in an Armor case with a small NVMe drive.  No need for thumb drives or Micro-SDXC memory cards this way.

I installed one Pi less than 3 weeks ago in the Yukon Denali I bought my dad the previous week. He hadn't been able to drive for 2 years due to a broken hip and long rehab and this was the vehicle he could get in and out of the most comfortably without risk of falling. He was like a 17 year old with his first vehicle and everything had to be "just right". He didn't care for the OEM wheel design so I ordered new sick looking chrome wheels with tires attached so I didn't have to deal with that. Added custom running boards and a half step under it to assist him getting in and out. He always like murals on truck back windows and had to have a USMC based one so I ordered and install an Iwo Jima mural he really liked. The last thing he wasn't crazy about was the onboard Entertainment center.  He kept commenting he wished it was more like our TVs (he was referring to Emby) so I loaded one of the Pi's NVMe up with movies and shows he liked as well as recordings of old time radio broadcasts he liked to listen to. Got the libraries scanned and then installed it in the truck.  It could boot and be streaming in under 30 seconds from power on. Instead of trying to connect the Pi to the entertainment center I instead used a Firestick which worked well. He still had all normal functionality but hitting the AUX button switched it to Emby. I even did a mod to allow playback while driving so he could listen to his stories.

He was happy and probably kidding when he said the Denali had everything but TV. I thought he was going to say "kitchen sink". After dinner I grabbed a spare HDHomeRun Quatro,  small window antenna (best I had on hand), travel router and short ethernet cable. After wiring up a single 12 volt power line to feed everything I took it out and tried it. About 20 minutes later I was downloading guide data off wifi.  I was mostly just goofing around and didn't think it would pull in any channels with that antenna but figured I could pickup a normal vehicle TV antenna the next day.  It got 6 channels including the 2 channels he wanted for NCAA Basketball and morning shows. He was still a bit uneasy driving but I think worried about our downhill driveway with cement siding the neighbor calls the "tunnel". He would take morning coffee and toast with his walker out and sit in it watching TV. Same with lunch a couple times.  He actually drove it I think 6 times before unexpectedly passing a couple days before Easter. 

Sorry for the long story but almost done. He was appreciate of everything of course but it wasn't the mural, deck, running lights, new wheels, custom license plate, personalized mats  or other things but Emby and the spare gear he fell in love with that made it his.

I shared that story as I think it shows I've done a lot of experimenting with the Pi and have used it in some unconventional ways as well as many OS and combinations.  Short of not having a Windows ARM build for it to test I've really had no issues TV wise.  That goes for using it as server or client using Theater or Kodi. This is all recent testing and I've only used the beta server software best I can remember. I don't know if the experience would be different on the release server or with less powerful Pis but all of my Linux setups have worked really well.

If there's any particular setup you know to be a problem I could try and test it. I could limit memory and change the clock rate to match other devices as well if needed.

[emveepee 112]

I wasn't meaning the RPi as a server, I too am surprised how good a server it can be when no transcoding is required.  I know a browser interface is not going to cut it as an for anything other than IPTV, so I am now eagerly waiting to fire up the Emby Theatre on it.  Generally users don't like running native Linux on an RPi so I will try your image.   I still have reservations for this as a "perfect" replacement for Kodi since their are great clients for ARM too and I feel the ODroid N2+ with CE for PVR is far superior to the RPi4 and native ARM OS playback won't cut it.  The N2 it is also my Linux client of  choice. 

Thanks for your story.  My interest in PVR is primarily because of small clients like these that offer high quality native playback.  For my backstory my emveepee username came about when I was writing software for the Hauppauge MVP https://www.cnet.com/reviews/hauppauge-mediamvp-review/ using something called mvpmc http://www.mvpmc.org/ .  Before PVR I just wanted to get Internet Radio using something called SlimServer into my stereo, then I released I didn't even need SlimServer .   My interest developed into supporting PVR clients for MythTV and VDR and then for at the time GBPVR for Windows.  Back then playing MPEG2 SD on a PC  was a challenge so this type of device was important.

Eventually when HD and H264 became important and MKV containers became popuilar a device called the PopcornHour came out https://www.linuxjournal.com/article/10215 I was fortunate that the vendor allowed me sign an NDA and write native clients for it.  It took many years for an Intel PC to catch up and that device was legend for scene support.  We never got MythTV working well on it, but GBPVR was great, and some users still use it.  Another old PC PVR  software company SageTV used (un-credited)  mpvmc based software and this led to their family of products for the MVP and other dedicated clients that are still well loved by their community.

Anyway, more on topic,  IMO a NextGen PVR needs a NextGen direct play client and it shouldn't need to be an 'HTPC' or a Shield.  Cheap newer Android devices and Apple  can be  excellent clients, (I have reservations about Roku for direct play so can't say excellent) but the devices that CoreElec and LibreElec support are great too especially for direct play support of many containers.  I also find there is nothing like a remote with a number pad when  watching Live TV put that is a personal preference.

Martin

[CharlieMurphy 73]

I always thought that having a fully open source option to compete with Roku or Google TV is a bigger deal than people realize maybe. And we have been close for so long. It's really good to see someone on the Emby team cracking out on RPi.

@cayars Sorry for your loss. That is a really touching story, thanks for sharing that too.

5 hours ago, emveepee said:

I also find there is nothing like a remote with a number pad when  watching Live TV put that is a personal preference.

I agree! I think some of what you said went over my head though, what do you think is the best device to get that?

The 'TiVo 4k streaming stick' has a remote with the number pad, which works in Emby. That's Android TV, I can't endorse it otherwise.

[emveepee 112]

2 hours ago, CharlieMurphy said:

I agree! I think some of what you said went over my head though, what do you think is the best device to get that?

The 'TiVo 4k streaming stick' has a remote with the number pad, which works in Emby. That's Android TV, I can't endorse it otherwise.

We are off topic, but personally I don't think there is a best device for direct play broadcast right now.  With the right Emby server that might not matter but there are too many variables in what people watch and how they watch (auto framerate, audio pass through etc).  I tend to recommend less sophisticated devices and when its on sale I do like the TiVo myself as a client, but not for their software, since I deTiVo it. The Android 10 update made it a little better and the number keys really help.    Shield fanboys might wonder why I don't respond with it, simply because for me the high price, crappy PVR remote and no AC-4 audio aren't a great mix in 2022.

More on topic, I just tried Emby on the TiVo 4K and it is way, way more polished then the RPi client (which I also just tried today).  I didn't see how to get comskip working but I also didn't spend a lot of time on that.  The remote number keys do work on the Android TV, but it seems only in the guide.  There is an OSD for changing channels directly but it doesn't seem to do anything except flash a channel icon.  So after this brief testing, I will stick with my comments that Emby clients are an important part of NextGen PVR especially when you isolate Emby they really need to be better sooner.

Martin

[Armageus 67]

On 02/05/2022 at 22:35, cayars said:

Nothing has dried up. We're getting a stead set of new features and improvements in the current beta which is rock solid.

Stable releases have all but dried up - 7 months between releases is terrible, and even when we do get a "Stable" release it ends up full of untested regressions and requires several point releases to fix.

Smaller, faster releases with less features, and quicker time from Beta -> Stable would improve the user experience no end.

On 02/05/2022 at 22:35, cayars said:

Native support on many OS for Hauppauge is surely going to be a hit.
Personally I'm more excited for the HDHomeRun faster tuning and ability to share Mux for OTA.  In my area the 4 Muxes I would use most give me 12 channels which also happen to be what would be used most of the time (90%+ I'd guess).  With a tuner already locked to a Mux it's near instant tuning.

But when is Native Hauppauge support actually going to be released? It's been promised for as long as I can remember, and is already 5 years too late. With devices such as the HDHomeRun being more readily available is there even a need for Hauppauge support?

Generic tuner support (what were they called? BDA Drivers?) would be far more of a hit.

 

I'd happily dig out my USB Tuners and give Emby another go at some point - but still can't imagine it coming close to the experience of even a set top box from 10+ years ago in terms of instant channel tuning.

 

On 02/05/2022 at 22:35, cayars said:

Not sure how you conflate 4K rips to being illegally downloaded.  I think if you were to look at different threads, you would see that many of us do our own Rips from content we purchase and then optionally post process the content. Same with tone-mapping which has nothing to do will illegal activity.

The amount of people who actually buy 4K media is fairly limited, the amount of people with an appropriate drive to rip their own discs, even more so. Whilst I'm sure there are people like yourself who do rip their own media, there are far more who just download them (and indeed evidenced by the amount of "Server Operators" who post here requesting changes for their "Users")

 

[clarkss12 295]

On 5/3/2022 at 2:24 AM, cayars said:

He was happy and probably kidding when he said the Denali had everything but TV. I thought he was going to say "kitchen sink". After dinner I grabbed a spare HDHomeRun Quatro,  small window antenna (best I had on hand), travel router and short ethernet cable. After wiring up a single 12 volt power line to feed everything I took it out and tried it. About 20 minutes later I was downloading guide data off wifi.  I was mostly just goofing around and didn't think it would pull in any channels with that antenna but figured I could pickup a normal vehicle TV antenna the next day.  It got 6 channels including the 2 channels he wanted for NCAA Basketball and morning shows. He was still a bit uneasy driving but I think worried about our downhill driveway with cement siding the neighbor calls the "tunnel". He would take morning coffee and toast with his walker out and sit in it watching TV. Same with lunch a couple times.  He actually drove it I think 6 times before unexpectedly passing a couple days before Easter. 

 

Sorry for your dad's passing.......

[Carlo 4330]

19 hours ago, emveepee said:

We are off topic, but personally I don't think there is a best device for direct play broadcast right now.  With the right Emby server that might not matter but there are too many variables in what people watch and how they watch (auto framerate, audio pass through etc).  I tend to recommend less sophisticated devices and when its on sale I do like the TiVo myself as a client, but not for their software, since I deTiVo it. The Android 10 update made it a little better and the number keys really help.    Shield fanboys might wonder why I don't respond with it, simply because for me the high price, crappy PVR remote and no AC-4 audio aren't a great mix in 2022.

I pretty much agree with what you're saying at a high level as well. I've never had a TiVo so I can't comment on that but others have said they like it too. One of the problems with Live TV in general is that it's semi-region specific with different standards, functionality, resolutions, different hardware, etc. On top of that even in the same region Cable is different than OTA which is different than Sat which is different than IPTV. Then it starts getting more specific with some counties using actual subtitles for TV while some countries use Closed Captions (embedded in the video layer) that need supporting. Different scan and frame rates.  That adds up to a lot of different combinations just for basic tuning that need to be supported.

Besides this you get channels in different resolutions which are roughly SD, 720, 1080 with both interlaced and progressives transmissions which could be encoded in Mpeg2, H.264 or H.265 which may or may not have support on the device playing back the channel.

Then you get new standards like ATSC 3 which come out thanks to some "mastermind geniuses" using a new proprietary audio codec that no existing hardware supports (AC4).To say that Live TV is wonderfully complex is an understatement! 

Talking in general regardless of platform or software used, it's not to hard to understand why one person can say things work great while another person struggles to get a reliable recording of a 30 minute show.

From a software standpoint it's crazy how you need to handle these streams as a movie could be broadcast in 1080i in Spanish using AC3, but a commercial is English in  2 channel AAC and possibly a different resolution as well. Not only that but ever notice commercials are usually louder than the main content? These "scene" changes are great for IDing commercials but can give you headaches when transcoding especially on the fly!

That's just the basic input side of things from a PVR perspective.  Now you get to complicate things even more due to all the different devices you support with different abilities. Some devices support the transports used for all codecs, others don't, some don't support the ts transport and require HLS, some devices can handle interlaced content while others can't. Some devices understand what Closed Caption is while other only support true subtitles.

Most devices (some exceptions) are designed for streaming and support the protocols and codecs used by popular services but may not handle a TS transport stream at all requiring at minimum a container change (direct play) to HLS. Of course HLS has specific requirements that further complicate things if the channel uses a video codec that's not supported.

It's crazy what must be done to view some TV channels on some devices and all the transformations/handling that need to take place while another channel and device make it simple.

Even the mighty Shield TV is "quirky" handling Live TV with the default player as it can be set to direct play but can't support trick play this way (pause, FF, RW, etc) but requires direct streaming (container switch) for trick play support. The new Android client is much better for Live TV (in my region and setup) with it's custom handling so I can't wait for that to be ported to other clients like Android TV for use on the Shield TV.

20 hours ago, emveepee said:

More on topic, I just tried Emby on the TiVo 4K and it is way, way more polished then the RPi client (which I also just tried today).  I didn't see how to get comskip working but I also didn't spend a lot of time on that.  The remote number keys do work on the Android TV, but it seems only in the guide.  There is an OSD for changing channels directly but it doesn't seem to do anything except flash a channel icon.  So after this brief testing, I will stick with my comments that Emby clients are an important part of NextGen PVR especially when you isolate Emby they really need to be better sooner.

Martin

Comskip would need to be setup on the Server side of things via script likely called from post processing. IMHO, this really should have been built in by now as a standard recording feature.  Using number keys is something that each client platform is going to need to support on all TV screens not just the guide. It may not be possible to use numbers on some platforms but on most you can enter numbers in some fashion even if the stock remote doesn't have them.  With wifi and bluetooth devices, programmable IR remotes and similar as well as CEC the ability to enter numbers is possible on most devices these days.

I agree with you about the clients needing some spit and polish. Little things like full support for channel change or guide jumping enter a number go a long way toward easier usability and "stock TV" emulation.  I don't think anyone would think it's a bad idea to have the best native TV support possible in each client but it's not so simple as many think. Some of the things added for testing in the new Android client will go a long way for anything based on Android (mobile or TV). Anything based on Windows or Linux should in theory be best of class  as well since theses are nearly limitless rich programming environments without the limitations some devices have.

Live TV is being heavily worked on at present in many different areas that will improve things. Many recent client releases have new TV fixes/features and there have also been new OSD improvements and additions specific to TV as well.

So it's not like Emby is sitting on it's hands doing nothing. The devs are hard at work with incremental changes/fixes in each release (front or backend) improving the TV experience piece by piece.

If only we had 48 hours days!

[Carlo 4330]

6 hours ago, Armageus said:

Stable releases have all but dried up - 7 months between releases is terrible, and even when we do get a "Stable" release it ends up full of untested regressions and requires several point releases to fix.

Smaller, faster releases with less features, and quicker time from Beta -> Stable would improve the user experience no end.

Emby has been making steady release of the software. Are you referring to one specific part? I'm assuming you mean Server?

That's just how development sometimes goes. If improvements require changes on the front and backend to work together it's going to be a longer cycle. Sometimes you can have 99% ready to go but have to wait on one small piece to finish it's cycle before you can make a release. Sometimes you could make a release but get feedback on improvements that could be made that you agree with and want to do that first since it would be a solid improvement.  All kinds of reasons.

There is no formal release time table Emby uses except "when it's ready". Some companies do releases based on a calendar like every quarter or twice a year, other companies might have one big release every year or two.

Emby has both releases and pre-release versions we call "beta" available for anyone to use on any platform.  We use the term "beta" since it's a common name most people understand but doesn't always mean "beta" in the true sense of development.  It's really "pre-release" that depends.  Sometimes things are added for testing and feedback or what you could call an experiment.  Doesn't happen often but once in a while.  These types of betas are clearly talked about.  Most of the time this type of thing is now handled pre-beta with selected users and only they are given the code to test and give feedback.  This has been working well the last year or so. So you could consider a "beta", a pre-release or release candidate depending on the status. Doing it this way allows any user to pick a version they wish to run.  You may not want the latest beta, but 2 version back that's solid without the latest/greatest new code.

The way Emby does it's "beta" allows you to pick what works for you. Maybe you want the latest what a lot call "nightly" or a version or two back which on quick releases would be a release candidate.  If there are 10 new things in the beta since the last master release you know these did not get added at one time but in sections with each new beta something new. The first deliverable beta would have the most use timewise and changes if needed, while the latest has no fixes to anything just added as it needs testing. anything between those two points will be somewhere in between.

The ideal method is to setup a test server where you help test and give feedback. When any particular beta is rock solid for you on your test machine you could use that for your production machine as well since you've vetted it. Some betas you may choose to skip for production if there's a quirk so report it and test again in a later release. If you do this the naming becomes moot and you'll never care if it's beta or release as named.  It get's tested in your environment and used if worthy. Maybe you're always 2 release behind the beta doing it this way.  Point is you can have your own rolling release on any timescale you want if you stop thinking in terms of "Release" vs "Beta".

Think about it.  If the current "beta" is called that simply because it's waiting on a change in the Roku client but you don't have any Roku clients does it matter what it's called?
A "Release" is really just a tag that says the ecosystem as a whole is ready.

If you read the forums you'll see that many people run the beta and have it auto installed and have been doing so for years without major problems. Others do as I mentioned and do their own vetting applying what works in testing to their production systems and have no issues. Others only run Releases but with any software could have a glitch that was never caught in beta. Obviously the more people involved in testing the better it is for everyone and the more chance there is to find an issue that is unique in some way to a system.  That's why the best thing you can do for yourself and others is to setup a test machine to install and run from even if it's just super basic and limited.  If no other reason it allows you to vette the software for your own use be it a beta or a release.  On PCs and Linux you can run multiple version of Emby (different ports setup) on the same machine making the process pretty easy as well.

7 hours ago, Armageus said:

But when is Native Hauppauge support actually going to be released? It's been promised for as long as I can remember, and is already 5 years too late. With devices such as the HDHomeRun being more readily available is there even a need for Hauppauge support?

Generic tuner support (what were they called? BDA Drivers?) would be far more of a hit

The amount of people who actually buy 4K media is fairly limited, the amount of people with an appropriate drive to rip their own discs, even more so. Whilst I'm sure there are people like yourself who do rip their own media, there are far more who just download them (and indeed evidenced by the amount of "Server Operators" who post here requesting changes for their "Users")

 Hauppauge and BDA support were part of the Live TV testing project.
The current server build introduces a new TV plugin framework.  Once the new framework is released it opens the door to adding many things from the earlier project related to new tuner support which included BDA and Hauppauge support.

Sorry I can't give you a timeline or date except to say this steps needed to delivery these is already in motion.

A lot of people rip 4K media just as they do DVD or Blu-ray.  I don't disagree that other people acquire media via download in some manner but I doubt the resolution makes any difference.  Those who rip will rip and those who download will download but I doubt the choice is 4K relates is my point. How a person acquires their content is their business not mine, but don't ask or expect my help with such activities.

[emveepee 112]

I think Live TV is too general a term, there is watching Live TV and there is also recording Live TV which is content, and Emby does content very well.   For my content I don't need the STB experience (but I do need comskip)  However for Live TV I don't want content, show me the game and let me switch easily to another game during a commercial.  Make it just like watching for a lack of a better word TV.  I rarely even need to look at the full guide via the client.  I guess Emby have done the research and their users like all that Live TV meta info on startup.  I personally simply ignore all the suggestions that Android launchers gives me on startup, and then the suggestions that Emby gives me and skip the Programs View .

Note also we weren't talking about TiVo the service,  it was the TiVO 4K the Android device https://www.tivo.com/products/stream-4k and more specifically their remote with number keys.  I think if you tested your Android app more with number keys you'd see what I mean.  Your Android app is actually pretty close  but the RPi app is far behind.

Martin

[CharlieMurphy 73]

24 minutes ago, emveepee said:

Note also we weren't talking about TiVo the service,  it was the TiVO 4K the Android device https://www.tivo.com/products/stream-4k and more specifically their remote with number keys. 

At one point, with some combo of versions that I couldn't tell you, I feel certain that the number pad worked while a stream was going on the TiVo Stream 4k. I don't have one set up to test right now though. I will set it up again soon.

[emveepee 112]

The numbers work in the Guide not the Channel List.  During Live TV, the numbers show when clicked and it even pops up the channel, but DPAD centre just flashes the channel icon when I hit it.  I can navigate to the OSD guide button on the bottom and change by number there.  On Android the channel numbers don't even show in the Channel List like they do on the browser.

Like I said it is close.

Martin

Edit:  It actually works with the number without the guide too when there is guide data.  There is an issue in 4.7 populating my guide data so I might see it more than others.

Edited May 5, 2022 by emveepee

[Spaceboy 2493]

11 hours ago, Armageus said:

Generic tuner support (what were they called? BDA Drivers?) would be far more of a hit.

 

 

 

so much this. the even more annoying thing is that it was done and abandoned

[Carlo 4330]

It wasn't abandoned. That was a separate test version not built on the same server backend structure that's used.

Many of the things that were tested then are making their way into the product server piece by piece. 
Some things in the current server also need to be changed to accommodate some of that as well which is currently in beta.
The current plugin framework was drastically changed to accommodate these types of things. It's currently in beta and being tested with fixes being applied to issues found.

So it's in the works but needs a systematic approach.

 

[pmac 132]

On 18/01/2022 at 14:30, BillOatman said:

I would not call that butchering.

1) It added a TVG_id to link to the xmltv entries.  I believe Emby and the others require xmltv entries to display channels.
2) Added a group, which really helps if you have a lot of channels (not so much with Emby yet, but for things like TiviMate it's huge), and the channel name at the end (same as the tvg-name)
3) It changes the link to point to itself in this case so that it can provide buffering and only use 1 provider stream no matter how many of its clients are watching the same show.  I think if you turn off the self streaming it will redirect the client to the providers stream.

All worthwhile additions IMO. Remember xTeVe was not written to be a simple channel editor.  It was written to trick Plex into playing IPTV by spoofing as a HDHomerun.

I know this is an old post, but I'm just now trying my first foray into using a paid iptv provider. Does using xteve's built in buffer still allow you to use multiple streams at once while only using up one stream slot from the provider? 

I'm already using xteve, but only to combine multiple epg's into one file that's easier to map on different devices than multiple xmls

[BillOatman 500]

1 hour ago, pmac said:

I know this is an old post, but I'm just now trying my first foray into using a paid iptv provider. Does using xteve's built in buffer still allow you to use multiple streams at once while only using up one stream slot from the provider? 

I'm already using xteve, but only to combine multiple epg's into one file that's easier to map on different devices than multiple xmls

No. It helps prevent some stream buffering.

You might want to look at  iptvboss  as a replacement for xteve.

[pmac 132]

12 hours ago, BillOatman said:

No. It helps prevent some stream buffering.

You might want to look at  iptvboss  as a replacement for xteve.

I am using iptvboss for channel/group management (yes, I've got a bit of a convoluted setup right now, lol). I plan to tidy up my setup once I get my head wrapped around the whole process/best practice. 

So, should I use iptvboss for management, and xteve as a proxy/buffer? Some of the tutorials I've read said that people have moved away from using xteve's buffering capabilities, but I don't know enough about it to fully understand why. 

I need to be able to combine my XML sources into one file that I upload to dropbox on a schedule, and I'm using a local M3U that I've pruned unneeded channels from my providers m3u, as well as added a handful of my own channels to. 

[CharlieMurphy 73]

xTeve has been abandoned and Threadfin picked up where it left off. If you do need xTeVe, I think Threadfin would be a nice upgrade. I don't recommend using either with Emby. Emby doesn't need HDHomerun emulation from xTeVe. Any other feature you may need xTeVe/Threadfin for, I have much preferred TVHeadend instead.

59 minutes ago, pmac said:

I need to be able to combine my XML sources into one file that I upload to dropbox on a schedule, and I'm using a local M3U that I've pruned unneeded channels from my providers m3u, as well as added a handful of my own channels to. 

IPTVBoss for this. It has "Universal EPG" as an option so you can have one shared EPG file for different playlists, aka "layouts". However, for what you are describing you may not even need the "universal EPG", IPTVBoss will combine the guide data from your playlist/layout into one XML output file anyway.
I don't use the Dropbox features in IPTVBoss, I sync with a script, but I've tested it in IPTVBoss and it worked well.
Another piece of advice is that instead of using IPTVBoss with outside XMLTV guides, use the built in data sources. They put a lot of work into upkeep of their sources I think.

[CharlieMurphy 73]

1 hour ago, pmac said:

people have moved away from using xteve's buffering capabilities, but I don't know enough about it to fully understand why. 

IPTV sources, in my experience, are imperfect. "Continuity errors," "transport errors," etc. What makes a good player is how it handles errors. Does it freeze on a frame and never recover until you back out of the video and play it again? Or does it freeze for a second and then recover and continue? Or does it freeze then recover, but with sound out of sync?

My take is that I found that having xTeVe involved made streams unlikely to handle issues, and maybe even introduced issues. I can't stand how it handles channel name changes and messes with channel numbering.

[BillOatman 500]

1 hour ago, pmac said:

I am using iptvboss for channel/group management (yes, I've got a bit of a convoluted setup right now, lol). I plan to tidy up my setup once I get my head wrapped around the whole process/best practice. 

So, should I use iptvboss for management, and xteve as a proxy/buffer? Some of the tutorials I've read said that people have moved away from using xteve's buffering capabilities, but I don't know enough about it to fully understand why. 

I need to be able to combine my XML sources into one file that I upload to dropbox on a schedule, and I'm using a local M3U that I've pruned unneeded channels from my providers m3u, as well as added a handful of my own channels to. 

You probably don't need the buffering.  One of its big uses was if 2 or more emby users are watching the same stream, xteve would feed them all from the same buffer and only one IPTV stream was used.  Emby does that for you now.