Jump to content

Simultanious scheduled recordings


dcol

Recommended Posts

Yes, theoretically there are 2 conditions like you mention for knowing how many tuners are available which are basically the known and the unknown.

If you have an Emby server with PCI or USB tuners you can for the most part consider them devoted to the the DVR. Or at least you the admin can control this via setup by not setting up multiple programs to use it.  IPTV could also be setup and handled like a PCI tuner in that if only the admin knows the username/password or specifics of the IPTV provider then it can't be used by any program except Emby.

Network tuners like the HDHomeRun models are a bit different.  Short of putting them on a VLAN or a subnet of their own it's hard to lock them down as they advertise via UPnP to the network and can easily be used a number of ways outside of Emby. IPTV could also fall into this camp as well as some of the features of IPTV likely won't make it into any DVR.  Many an IPTV have the ability to watch most channels from 12 to 48 hours in the past.  So if you missed a show on tonight you can "rewind" and watch it tomorrow.  Thus if you use this type of feature in a standard IPTV player a stream will not be available to the DVR.

There is yet another unknown but calculable situation with something like a Connect where you can have several channels on a mux. So the 4 tuner model could at times be recording 10 to 12 channels with only the 4 tuners if lucky.

Then of course in a smart DVR, multiple people will be able to schedule recordings but should all people be created equal in establishing the priority of recordings?  If both the admin and spouse set something to record at the same time and only 1 tuner is available what does it record?

Regardless, of the known tuner count there is always another variable or two that won't be known until recording time.  What if there is a hung tuner OR a person watching Live TV on a channel not being recorded.  Do we boot them to use the tuner or work around them?

With a "smart DVR" all this would be taken into consideration and could still use the "pre-schedule" method while hoping for the best while handling the worst.  In an ideal world every recording would have a priority set at recording time where the user picks how important it is to record from 1 to 3 or 1 to 5 or something like that where it's basically a HIGH, MEDIUM or LOW priority.  How important it is would get used at recording time to allocate tuners assuming all are online. The DVR would also "look ahead" to see what movies/episodes are rebroadcast in the GUIDE and could use this as well in determining what to record when limited on tuners.

So yes in an ideal world/theoretical DVR there is a lot going on and it will be much more complicated than a lot of people would ever consider. 

But most of this is about possible future enhancements. It doesn't change basics, like what ever was scheduled to record, should be recorded as best as possible with retries the entire recording if something goes wrong.

Link to comment
Share on other sites

8 hours ago, cayars said:

In an ideal world every recording would have a priority set at recording time where the user picks how important it is to record from 1 to 3 or 1 to 5 or something like that where it's basically a HIGH, MEDIUM or LOW priority.

Very correct - such kind of priority levels would be required as well 😉 

Link to comment
Share on other sites

embysysadmin

Working within the timeframe of a scheduled recording (picking say a one time sport event) and a personal desire (actually my spouse's desire) to see only one recording for that event, is it possible to on the fly "splice in" an 'Emby Stream Trouble' slide stream after the first second of stream failure. Let the recording continue with that slide up, while the server retries the stream on a sliding scale in the background. I don't think that the top  end of the retry scale, say once every 2 minutes would be "hammering the provider". Then Emby would have a "complete" recording with no issues and the "user" would have one complete recording to search through and maybe find useable content.

Showing my age here in picturing a typical user experience. A VHS recorder would record ABC Monday Night Football for the scheduled time in the VCR, no matter how many times the local ABC affiliate went off the air in a thunderstorm and/or how many times ABC network or the local affiliate put up a "Please Stand By... Network Trouble" slide. One just hit the FF button many times and hoped the "signal;" was there as the 4th quarter clock was running out. Oh, dang it... A tie score and overtime. Never saw the final score. Never blamed the VCR.

One of the live local affiliate series streams I record is a network show at 6:30. Generally, but not always a complete 31 minutes. Always assumed a stream glitch, because when I check the stream about 8PM or so it is always there. I never blame Emby and never check the logs.

  • Like 1
Link to comment
Share on other sites

1 hour ago, embysysadmin said:

Working within the timeframe of a scheduled recording (picking say a one time sport event) and a personal desire (actually my spouse's desire) to see only one recording for that event, is it possible to on the fly "splice in" an 'Emby Stream Trouble' slide stream after the first second of stream failure. Let the recording continue with that slide up, while the server retries the stream on a sliding scale in the background. I don't think that the top  end of the retry scale, say once every 2 minutes would be "hammering the provider". Then Emby would have a "complete" recording with no issues and the "user" would have one complete recording to search through and maybe find useable content.

When you say "splice in", then that's just two words, but incredibly complicated, and when you would have that working perfectly for arbitrary codecs and stream properties after a lot of development effort, you would have a different product for a different audience and with a very different pricing model.
So, forget about "splicing in".

What could be realistically be done is:

  • Cover short outages without splitting recording files
  • Display your "stream trouble" slide in client applications
    it's not part of the video, the client app just get's the information and displays the "slide" as an image
  • In case when there are  multiple recording segments - play those subsequently in client applications
    (maybe with a short notice that some part is missing and gets skipped)
  • Post-process multi-segment recordings, concatenating to a single file (with or without gaps being filled with blanks or "trouble" image)

That doesn't mean that we'll do all of this - it's just to explain what's possible and what not.

We are currently to .ts files which is actually not even a file format - it's a stream specification (MPEGTS). When you leave out China, more than 90% of digital TV broadcasts are using MPEGTS. But as it is a transport stream and not a file format, it becomes invalid when a stream doesn't continue anymore. Unlike analog TV, where you could continue recording the noise, that doesn't work with digital TV. There are error correction and validation mechanisms in place (e.g FEC), and when there's no more valid content being received, there's no more stream coming in. As we cannot "splice in" something, a stream file becomes invalid because there's no longer a stream. We cannot continue that stream in the same file later, because the resulting stream file would contain an invalid stream (because a stream is not allowed to "jump forward" in time).

That's one reason (among others), why Microsoft had invented a special file format for Windows Media Center: WTV. The WTV file format allows having gaps (some might remember the blue picture when reception had gone bad). But even WMC stopped recordings after some timeout, when there was no signal anymore.

Introducing a custom file format is beyond our capacity. So, the next best option we have is to record on or more mpegts segments and save some metadata information for those segments. That's similar to what WMC did (with regards to recording gaps), just that we're not putting it all into a single file.

(this is still very simplified, but I just don't have enough time to go deeper into this)

Best regards,
softworkz

 

Link to comment
Share on other sites

embysysadmin

Thanks for your reply. If this were an in person conversation the words "splice in" would have been in air quotes. Yes, it's complicated. My career for 42 years was television broadcast engineering. I made the transition from analog through digital television and watched development and use of most every codec  and container format there is. The reason I can tag unix (and unix like) system admin for 42 years is that we pulled and reconciled programming logs through VAX/VMS hardware/OS. When I started the career, my employer said you know fortran, cobol, and algol... the VAX is yours. I went through the rise and fall of Silicon Graphics (SGI) and Irix and stayed with Linux and OS-X administration until my retirement. Funny, now in retirement nothing has changed from the last 15 years of my career. I've got you the vendor, me the on site engineer, and my spouse the client. By the way, I worked ABC Monday night football whenever it was from the old Atlanta Stadium. Our mobile unit and crew was under contract.

I understand and appreciate everything on your end.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...