Jump to content


Photo

Recording issues


  • Please log in to reply
846 replies to this topic

#801 dcol OFFLINE  

dcol

    Advanced Member

  • Members
  • 1028 posts
  • Local time: 09:12 AM
  • LocationTucson, Arizona

Posted 08 June 2019 - 01:41 PM

I am running two Emby beta servers. Both use xTeVe playlists with one using the beta with buffer and the other the stable version without buffer.

 

The server which did not use the xTeVe buffer recorded 10 shows fine last night. The server with the buffer had mixed results last night. Out of 10 recordings, only 3 were perfect. The rest had a mixed bag of issues. On one channel that had three recordings, they all ended within 5-10 minutes. There were no good recordings on that channel. Another show had PCR to PTS Drift issues and recorded half the show. The rest of the bad shows ended early. Did not see any weird show length times like before 4.2.0.14

 

My conclusion to this is Emby 4.2.0.14 seems to work fine when there is no pre-buffer, as in xTeVe, in the stream. The xTeVe buffer must not be compatible with the way the new algorithms detect timestamps.


Edited by dcol, 08 June 2019 - 01:41 PM.


#802 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 138076 posts
  • Local time: 12:12 PM

Posted 08 June 2019 - 02:02 PM

Why even use the extra buffer layer?

#803 dcol OFFLINE  

dcol

    Advanced Member

  • Members
  • 1028 posts
  • Local time: 09:12 AM
  • LocationTucson, Arizona

Posted 08 June 2019 - 02:10 PM

Just reporting results and testing it, Also, I like the limit connection feature in the xTeVe buffer. Better than using group titles in Emby to limit the simultaneous connections.

 

Let me explain that. If you have multiple IPTV providers, each with a different connection limit, it is best to set that limit as to not get banned from the provider. Emby can do it per m3u, but that means that I need to setup a way to get xTeVe to differentiate between the different providers. Then you have to modify the group titles and import the m3u's that way.

 

If there is a better way to pass multiple modified m3u's with connection limits to Emby, please share.


Edited by dcol, 08 June 2019 - 02:13 PM.


#804 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1784 posts
  • Local time: 06:12 PM

Posted 08 June 2019 - 07:50 PM

I am running two Emby beta servers. Both use xTeVe playlists with one using the beta with buffer and the other the stable version without buffer.

 

The server which did not use the xTeVe buffer recorded 10 shows fine last night. The server with the buffer had mixed results last night. Out of 10 recordings, only 3 were perfect. The rest had a mixed bag of issues. On one channel that had three recordings, they all ended within 5-10 minutes. There were no good recordings on that channel. Another show had PCR to PTS Drift issues and recorded half the show. The rest of the bad shows ended early. Did not see any weird show length times like before 4.2.0.14

 

My conclusion to this is Emby 4.2.0.14 seems to work fine when there is no pre-buffer, as in xTeVe, in the stream. The xTeVe buffer must not be compatible with the way the new algorithms detect timestamps.

 

There are different ways to fix timestamps and I've implemented different variants:

  1. Based on constant bitrate
    This algorithm only works when the TS stream bitrate is constant
    It detects the bitrate from the stream contents and recalculates PCR values based on this bitrate as soon as they are getting off more than a certain detla
    Then there are two subvariants:
    • a: Recalculate PTS and DTS based on the PCR
    • b: Recalculate PTS and DTS keeping their previous offset to PCR
  2. Relative fixup
    This is a pure relative fixup. It works for streams with non-constant bitrates, e.g. streams that have been processed by ffmpeg or where certain streams have been dropped and there is no constant bitrate
    This algorithm maintains relative PCR values and adjusts when PCR delta values are negative or larger than expected.
    PTS and DTS are then adjusted like with 1b

 

What's currently being used is #2. The former one is rather meant for processing hardware streams where bitrates are guaranteed to be constant.

 

I don't know xTeVe and getting compatible with 3rd party products is not really a primary goal, so I think any time to invest will be much better spent for getting stream limits working better than currently.

This will be part of some bigger effort which will probably also include the ability to have multiple sources per channel. 



#805 denz OFFLINE  

denz

    Advanced Member

  • Members
  • 2170 posts
  • Local time: 12:12 AM
  • LocationPerth, Australia

Posted 09 June 2019 - 04:00 AM

It is only in the first minute that it has very high usage then it hovers around 10% for two recordings. 

 

If I look at the resource monitor after a five minutes span the average is 7.8%.

 

 

5cfcb8fb1bb07_Capture2.png



#806 DarWun OFFLINE  

DarWun

    Advanced Member

  • Members
  • 301 posts
  • Local time: 12:12 PM
  • LocationToronto, Ontario, Canada

Posted 09 June 2019 - 01:18 PM

@softworkz @Luke

 

After updating to 4.2.0.14, recording no longer works. I compared a log from 4.2.0.12 with one from 4.2.0.14, and everything is the same up to the point where the live stream opens. On 4.2.0.14, the stream does not open. Even though the record icon shows up in the guide, there is no media file in the recordings folder. I've attached logs. Successful recording with 4.2.0.12 starts at 12:38. Failed recording with 4.2.0.14 starts at 12:49.

 

Cheers,

   DarWun

 

 

Attached Files



#807 denz OFFLINE  

denz

    Advanced Member

  • Members
  • 2170 posts
  • Local time: 12:12 AM
  • LocationPerth, Australia

Posted 09 June 2019 - 11:50 PM

Not a big issue but If you have pre and post padding it always displays 1 minute less in the details. I have set up pre and post 2 and 10 when I go to watch a recording in the timeline it has 41.56 and on the other one it may have 41.90.

 

I would prefer if it was rounded.  



#808 dcol OFFLINE  

dcol

    Advanced Member

  • Members
  • 1028 posts
  • Local time: 09:12 AM
  • LocationTucson, Arizona

Posted 10 June 2019 - 10:48 AM

@softworkz

 

22 out of 22 perfect recordings yesterday. Good job!!



#809 dcol OFFLINE  

dcol

    Advanced Member

  • Members
  • 1028 posts
  • Local time: 09:12 AM
  • LocationTucson, Arizona

Posted 10 June 2019 - 11:16 AM

Moved to new thread


Edited by dcol, 10 June 2019 - 12:11 PM.


#810 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1784 posts
  • Local time: 06:12 PM

Posted 10 June 2019 - 12:11 PM

It is only in the first minute that it has very high usage then it hovers around 10% for two recordings. 

 

If I look at the resource monitor after a five minutes span the average is 7.8%.

 

 

5cfcb8fb1bb07_Capture2.png

 

I can't diagnose from here, maybe your provider has some buffer amount that is transferred initially and causes a moment of higher CPU usage until it approaches "live speed".

Anyway, this was out first shot and we got still room for improvement..



#811 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1784 posts
  • Local time: 06:12 PM

Posted 10 June 2019 - 12:15 PM

@softworkz @Luke

 

After updating to 4.2.0.14, recording no longer works. I compared a log from 4.2.0.12 with one from 4.2.0.14, and everything is the same up to the point where the live stream opens. On 4.2.0.14, the stream does not open. Even though the record icon shows up in the guide, there is no media file in the recordings folder. I've attached logs. Successful recording with 4.2.0.12 starts at 12:38. Failed recording with 4.2.0.14 starts at 12:49.

 

Cheers,

   DarWun

 

@DarWun - Thanks for reporting, this seems to be a packaging problem:

 

5cfe817329b8b_dataflow_packaging_problem

 

@Luke



#812 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1784 posts
  • Local time: 06:12 PM

Posted 10 June 2019 - 12:22 PM

Not a big issue but If you have pre and post padding it always displays 1 minute less in the details. I have set up pre and post 2 and 10 when I go to watch a recording in the timeline it has 41.56 and on the other one it may have 41.90.

 

I would prefer if it was rounded.  

 

This is not really a discrepancy, it's rather a display format issue:

 

  • 41:56 means 41 min and 56 s
  • 41.90 means 41.9 min where 0.9 min == 56 s

Where did you see the latter one?



#813 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1784 posts
  • Local time: 06:12 PM

Posted 10 June 2019 - 12:25 PM

@softworkz

 

22 out of 22 perfect recordings yesterday. Good job!!

 

Thanks for the update! So these were done without the 3rd party product I guess?

 

PS: For the stream limit issues, there's now at least a plan how to deal with this in a precise way.



#814 dcol OFFLINE  

dcol

    Advanced Member

  • Members
  • 1028 posts
  • Local time: 09:12 AM
  • LocationTucson, Arizona

Posted 10 June 2019 - 01:17 PM

Thanks for the update! So these were done without the 3rd party product I guess?

 

PS: For the stream limit issues, there's now at least a plan how to deal with this in a precise way.

Yes the third party app, xTeVe, caused issues. I turned the buffering off in xTeVe.

Also, although everything seems to play fine. Got some errors when I tried to convert one of those shows. I attached the log for your inspection. Has some interesting DTS errors in it. Timestamps look fine in finished file.

Attached Files


Edited by dcol, 10 June 2019 - 01:24 PM.


#815 denz OFFLINE  

denz

    Advanced Member

  • Members
  • 2170 posts
  • Local time: 12:12 AM
  • LocationPerth, Australia

Posted 10 June 2019 - 10:24 PM

Oops it wasn't 41.90 it was 41.59.  It is not a biggie but I would still prefer it to say 42 minutes rather than 41 minutes. 


Edited by denz, 10 June 2019 - 10:26 PM.


#816 maegibbons OFFLINE  

maegibbons

    Advanced Member

  • Members
  • 2337 posts
  • Local time: 05:12 PM
  • LocationLutterworth, England, UK

Posted 11 June 2019 - 03:30 PM

Hi

4.2.0.14 has not been so good for me. Up until the recent changes, I had absolutely zero issues with HDHR recordings whatsover.

The recordings were faultless and always showed the correct duration.

Now IPTV shows tend to show the right length but HDHR recordings are showing 828 minutes length for 30 min shows actually 34 with padding and 859 for 60 minute shows, 64 with padding.

It's all a bit screwed up.

Krs

Mark

#817 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1784 posts
  • Local time: 06:12 PM

Posted 12 June 2019 - 10:39 AM

@maegibbons - Thanks for the report. Actually the recent changes were primarily aimed for getting IPTV recordings right and that's what it was tested for.

 

There have been reports about HDHR recordings having timestamp issues sometimes as well - that's why we are running those through the same algorithm for testing.

 

@Luke - Maybe we should switch this off for HDHR and look into the HDHR timestamp problem separately?

(test recordings welcome - I mean from pre-.14)



#818 Senna OFFLINE  

Senna

    Advanced Member

  • Members
  • 1133 posts
  • Local time: 06:12 PM

Posted 12 June 2019 - 10:48 AM

@Luke - Maybe we should switch this off for HDHR and look into the HDHR timestamp problem separately?

In the streaming monitor of DVBLink I see My DVB-C provider feeding my HDHomeRun with CBR and VBR Live TV channels.

As far as I have read back this topic, those should be handled differently by Emby, right @softworkz ?



#819 dcol OFFLINE  

dcol

    Advanced Member

  • Members
  • 1028 posts
  • Local time: 09:12 AM
  • LocationTucson, Arizona

Posted 12 June 2019 - 11:23 AM

@softworkz

Had one failure last night @ 16:41:07. Show ended early.

Looks like the way Emby re-connected to the stream was not accepted by the IPTV provider which threw an HTTP 403 error.

This was the only connection to this provider at this time. Same provider recorded shows with no issues 1 hour prior and 1 hour after this one failed. Different channels.

 

By the way, I noticed that the providers private info is no longer shown in the log. Thanks for that !!

 

Attached is the log.

Attached Files


Edited by dcol, 12 June 2019 - 11:28 AM.


#820 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1784 posts
  • Local time: 06:12 PM

Posted 12 June 2019 - 12:59 PM

In the streaming monitor of DVBLink I see My DVB-C provider feeding my HDHomeRun with CBR and VBR Live TV channels.

As far as I have read back this topic, those should be handled differently by Emby, right @softworkz ?

 

No, not quite. What I had written was about the bitrate of the full mpegts stream's bitrate which is something very different from the individual video streams' bitrates.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users