Jump to content

Recording Episode or Series in Specific NextPVR Folder


rene.teniere

Recommended Posts

You can use this m3u approach, but it's not ideal (because Emby does not know what channels can be tuned at the same time with multi-rec etc). The safest way to add this is to add an m3u tuner with a maximum of 1 connection. You can repeat this for the number of tuners you have. 

 

When you add a tuner, you have to give it a client string to be included, like this:

 

http://localhost:8866/channels?client=emby-tuner1

http://localhost:8866/channels?client=emby-tuner2

etc.

 

If you got a low number of tuners, or want listings outside of US/Canada, or DVB EPG, you'd be much better off using NextPVR plugin.

Edited by sub3
Link to comment
Share on other sites

emveepee

sub, the main thing I am trying to establish is if Emby  is smart and has it's own multi-rec or is simply a dumb recorder of URL's  @@cayars said it is smart and I just want to confirm that before abandoning the idea of updating the plugin.

 

Basically using the m3u method for Emby recording,  on back to back recordings on the same channel, with the same client ID when I tested before Emby was dumb so when pre-padding started it killed the first recording early.  My other scenarios are all on the trying to use the same channel twice and is independent of how many tuners there are.

 

Martin

Link to comment
Share on other sites

SHSPVR

Again sorry I don't understand what you are saying but it is not what I asked.  I'd prefer to see the NextPVR logs of you recording in Emby and watching the same channel live (not the recording in Emby)

 

With four tuners you should be able to stream at least 4 channels and with sub channels even more , those US 23.1 23.2 etc are subchannels.  What I care about is trying one channel as both a recording and live tv or as two live TV channels (using m3u they are effectively the same method)

 

Martin

 

here what ask for with fresh set of logs from both npvr and emby just you ask for with it recording in Emby and watching the same channel live

emby_logs.zip

npvr_logs.zip

Link to comment
Share on other sites

SHSPVR

sub, the main thing I am trying to establish is if Emby  is smart and has it's own multi-rec or is simply a dumb recorder of URL's  @@cayars said it is smart and I just want to confirm that before abandoning the idea of updating the plugin.

 

Basically using the m3u method for Emby recording,  on back to back recordings on the same channel, with the same client ID when I tested before Emby was dumb so when pre-padding started it killed the first recording early.  My other scenarios are all on the trying to use the same channel twice and is independent of how many tuners there are.

 

Martin

 

Well as for back to back recording I been recording the old MacGyver show (3) 1 hours every saturday on same channel and all of them had per-pudding 1 before and 1 min after in them just like how I set it up in emby but may guest is it may have had to used a 2nd tuner in order to accomplish that if want I can setup some recording to see if that was case.

Link to comment
Share on other sites

emveepee

here what ask for with fresh set of logs from both npvr and emby just you ask for with it recording in Emby and watching the same channel live

 

Thanks a lot for that. Although I don't know Emby this is showing good news

 

2019-03-25 12:25:57.556 Info App: Live stream c0bd5b2159000afb3f8594c3615db902 consumer count is now 2

2019-03-25 13:01:00.103 Info MediaSourceManager: Live stream c0bd5b2159000afb3f8594c3615db902 consumer count is now 1

2019-03-25 13:10:52.416 Info MediaSourceManager: Live stream c0bd5b2159000afb3f8594c3615db902 consumer count is now 0

 

so really there is no advantage to using the plugin and the hack to map the channel and the station makes sense.  In your case since you are using a Hauppauge device it is no clear why you need to even bother with NextPVR but I assume that is because Emby still needs work.

 

For users with one tuner I don't think the client id hack is a good idea as there actually will be more failures.  If you have a mix of tuners in NextPVR you really need to be smart about setting up the m3u file by tuner.

 

If you are going the m3u route, I wouldn't even bother going through the trouble of setting up the EPG in NextPVR, there is no value if you are using Emby.

 

Martin

Edited by emveepee
Link to comment
Share on other sites

SHSPVR

Thanks a lot for that. Although I don't know Emby this is showing good news

 

2019-03-25 12:25:57.556 Info App: Live stream c0bd5b2159000afb3f8594c3615db902 consumer count is now 2

2019-03-25 13:01:00.103 Info MediaSourceManager: Live stream c0bd5b2159000afb3f8594c3615db902 consumer count is now 1

2019-03-25 13:10:52.416 Info MediaSourceManager: Live stream c0bd5b2159000afb3f8594c3615db902 consumer count is now 0

 

so really there is no advantage to using the plugin and the hack to map the channel and the station makes sense.  In your case since you are using a Hauppauge device it is no clear why you need to even bother with NextPVR but I assume that is because Emby still needs work.

 

For users with one tuner I don't think the client id hack is a good idea as there actually will be more failures.  If you have a mix of tuners in NextPVR you really need to be smart about setting up the m3u file by tuner.

 

Martin

 

Emby will needs the WinTV install for the Hauppauge Tuner to work and even then it has major problem see link below

https://emby.media/community/index.php?/topic/66462-36076-beta-recording-poroblem/

And there no need to setup M3U file by tuner I stick with &client= parameter as so far it rock solid even better then I was expecting and even better then using Cast4me which always to seem fail after week of run

Edited by SHSPVR
Link to comment
Share on other sites

sub, the main thing I am trying to establish is if Emby  is smart and has it's own multi-rec or is simply a dumb recorder of URL's  @@cayars said it is smart and I just want to confirm that before abandoning the idea of updating the plugin.

Emby does not do multi-rec.

Emby does not do any conflict resolution

Emby does not change times of recordings to free up tuners if a show/movie is on in another time slot

Emby does not have any priorities of tuners, channels, people, live vs recordings

Emby does not merge channels from anything other then same HDHomeRun types (ie 2 HDHomeRun Primes)

It's "dumb" in those respects compared to other higher end DVR/PVRs.

 

Using Next PVRin Emby can help with some of the things I mentioned above depending on how you use it and have it configured with Emby. You can load up OTA, Cable, M3U "tuners" and merge like stations into one channel that follows priorities of tuners.  It can make use of multi-rec to get you more "tuners" overall to use.

 

If you run it on another computer and need the streams in H.264 format you can have it convert the streams on the fly for you.  You can use it to re-arrange or change channel numbers.

 

Depending on how you set things up you can have NPVR do commercial skipping and start scanning the video while recording looking for the commercials to cut down the overall time needed.

Link to comment
Share on other sites

Ok great I guess Emby is treating streaming from URL's differently then when I last tried an entirely they must be creating a pipe or some other mechanism for sharing.

 

Your understanding of &client= still off A couple of test you can try

 

1) Multiple use ie simultaneous recording and live tv  or to Emby clients watching the same channel

 

start wget "http://localhost:8866/live?channel=3&client=3

wait

start wget "http://localhost:8866/live?channel=3&client=3

the second call kills the first connection

Don't know how far you got playing with this, but if you do what you just showed above it WILL kill the first stream and start a new stream because you issued it the same CLIENT parameter essentially telling NPVR I'm "changing channels, re-use the stream from client 3".

 

This would NOT happen if using Emby because it would already share the channel 3 stream.

2)Channel changing

 

start wget

start wget

 

requires two tuners (or DVB sub-channels) so users like me with several channels that are only on one tuner will fail on tuning however

 

start wget "http://localhost:8866/live?channel=4&client=3

 

will kill the first connection and frees up the tuner to go to channel 4

 

Martin

Not sure what you were trying to show with this but hopefully what I typed above clears it up.

Essentially, if what Emby sends has a new client id then an ADDITIONAL/NEW stream will be opened.

If the client ID is the same as one current then the current stream is CHANGED to the new stream.  From the standpoint of Emby we never want this to happen.

Link to comment
Share on other sites

emveepee

I never had any doubt that NextPVR is a higher end PVR at this stage of Emby's development but became curious why several users and Luke recommend Emby m3u.  This must be very confusing to new users and existing users alike, certainly it has been confusing for me.  Thanks for pointing out some weaknesses.

 

I did find Emby does multi-rec in the sense that streams from NextPVR can be used for multiple things.  Perhaps you mean simultaneous recording of sub-channels on one DVB or ATSC "channel".

 

Martin

Link to comment
Share on other sites

emveepee

Don't know how far you got playing with this, but if you do what you just showed above it WILL kill the first stream and start a new stream because you issued it the same CLIENT parameter essentially telling NPVR I'm "changing channels, re-use the stream from client 3".

 

This would NOT happen if using Emby because it would already share the channel 3 stream.

Not sure what you were trying to show with this but hopefully what I typed above clears it up.

Essentially, if what Emby sends has a new client id then an ADDITIONAL/NEW stream will be opened.

If the client ID is the same as one current then the current stream is CHANGED to the new stream.  From the standpoint of Emby we never want this to happen.

 

Actually shspvr logs demonstrated Emby is not sending a second http request on existing channels, internally it is managing open http streams so that first part is handled ok, whether or not the client in the m3u changes. 

 

There is an advantage to using multiple client parameters to allow multiple recordings with the m3u approach but the second test shows the problem with this approach for channel changing with one tuner.   If you change the channel NextPVR will tell the second "client" that the tuner is in use and the change won't happen.  Two tuners are required temporarily until the first client socket times out.   However with one client there will be an issue with pre-padding on channel changes.  The only solution seems to be to use the plugin.

 

Martin

Edited by emveepee
Link to comment
Share on other sites

There is an advantage to using multiple client parameters to allow multiple recordings with the m3u approach but the second test shows the problem with this approach for channel changing with one tuner.   If you change the channel NextPVR will tell the second "client" that the tuner is in use and the change won't happen.  Two tuners are required temporarily until the first client socket times out.   However with one client there will be an issue with pre-padding on channel changes.  The only solution seems to be to use the plugin.

Emby does the same thing with normal tuners as well.  This only happens AFAIK if you are watching something with the mini grid up and change channels. Emby tried to keep the "background" video working until it has enough data to actually switch to the new channel you just choose. 

 

If you bring up a channel from the Guide, exit, go back to guide, change channel this of course doesn't happen as there has been plenty of time to allow for the stream to close.  This is really something that should get changed in Emby as it affects all tuner types and is a problem when all the tuners are in use.

 

Concerning Multi-rec this is feature, which enables more than one channel to be recorded per tuner as long as the channels being recorded are being transmitted on the same digital multiplex. It does not apply to analog tuners, and whether it applies to QAM digital cable depends somewhat on your carrier and your hardware.

 

Emby does stream sharing pretty (what you observed) well but that's not multi-rec or recording multiple streams off one multiplex.

Link to comment
Share on other sites

emveepee

It's semantics, we are saying the same thing.  Emby has partial multi-rec in that multiple clients can watch or record from the same stream, have padding on back to back recordings. 

 

Martin

Link to comment
Share on other sites

It's semantics, we are saying the same thing.  Emby has partial multi-rec in that multiple clients can watch or record from the same stream, have padding on back to back recordings. 

 

Martin

It's not semantics really as multi-rec means something specific and Emby does ZERO multi-rec itself.  Tuner sharing is completely different and Emby does this well.

 

Emby can use one tuner:

To record or watch shows that overlap on the same channel due to padding (pre or post).

Allow multiple users to view the same channel from a single tuner.

 

Multi-Rec on the other hand allows one tuner to record different stations on the same multiplex.  For example in my area a couple of my multiplexes:

17.1, 17.2, 17.3, 17.4 (myTV, Antenna TV, this, Comet)

29.1, 29.2, 29.3, 29.4 (Fox, Movies!, LightTV, Buzzr)

47.1, 47.2, 47.3, 47.4 (ABC, CW, MeTV, ION)

61.1, 61.2, 61.3, 61.4, 61.5, 61.6 (ION, qubo, IONLife, Shop, QVC, HSN)

 

So with a 4 tuner HDHomeRun Quatro I could record all 17 (ion is on two muxes) of those channels using only 4 tuners with a DVR that supports multi-rec.  Of course the stars would have to line up perfectly. :)

 

Emby could then take those 17 different available stations and allow dozens and dozens of people to view them via sharing.

Link to comment
Share on other sites

emveepee

Multi-rec has more than one use and is a concept and not a word and you are focusing on one.  Let's drop this discussion since you aren't telling me anything new.

 

Martin

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...