Jump to content

Live TV Recordings Will Only Record For 19 Minutes


linuxmac
 Share

Recommended Posts

I've installed Emby on 3 separate servers (Debian, Ubuntu, and Mint) to test. All 3 have had the same issue. Recordings are stop short.

 

I'm using HDHomerun Prime which has that latest firmware.

 

All three Emby servers have the latest version 3.0.7200.0

 

I've tried resetting the Medadata from the 3 dots at the top right. No help

 

Tried changing the padding. No Help

 

 

*******************************

 

Help would be deeply appreciated

 

Thanks 

Log2.txt

Log1.txt

post-152050-0-66801100-1474163734_thumb.png

post-152050-0-46655600-1474164241_thumb.png

Edited by linuxmac
Link to comment
Share on other sites

Day three update...

 

I let the server run for a few days to see how it reacted.

 

The recording are recording in full length but now the server stops recording and even after a reboot the recording are still stuck in the schedule. 

 

I waited for the server to remove the recordings from the schedule but after an hour I decided to remove them manually.

 

 

 

I also updated to the newest Version 3.1.159.0 beta

 

 

I'll update back in a few days

 

server-63609840000.txt

ffmpeg-transcode-06c2ca72-36ab-4989-8e25-3a40b0db70e2.txt

ffmpeg-transcode-7ca30de5-7cf5-41c0-875f-60722192d9fa.txt

ffmpeg-transcode-94b3af5c-758c-4470-bad5-06bcad514d2b.txt

ffmpeg-transcode-18225506-1e8b-436c-9fa2-806879685e97.txt

post-152050-0-63739900-1474416329_thumb.png

post-152050-0-39390000-1474416330_thumb.png

post-152050-0-58494900-1474416331_thumb.png

Link to comment
Share on other sites

panamajim

Providing information for what appears to be a similar problem.

 

Two Emby servers in the house.  One is Windows, the other Linux.  My Windows Emby server shows the same behavior as OP except it only records between 9 to 16 minutes before it stops.  The schedule appears to hold the entries indefinitely.

 

Transcode and Remux log files attached for two shows that failed to record the whole show.  Both appear normal to me.  (But then again, I'm still quite new to this....)

 

Server log file attached.

 

Background info possibly interest:

I modified Emby to point to an updated static executable of ffmpeg.  The problem is unaffected

record-transcode-6f8103ec-7d26-4e8b-ad78-a9ed1e395b28.txt

record-transcode-232c5e45-9923-414c-afcf-768bcde7a0b2.txt

server-63609919145.txt

ffmpeg-remux-29cde690-56eb-4223-8a4b-2dff3224dfd3.txt

ffmpeg-remux-86881e4b-7141-4a8c-9e13-1ece7bd521ed.txt

Edited by panamajim
Link to comment
Share on other sites

Version 3.1.159.0 beta had the same problem of schedule not continuing.

 

I to Version 3.1.161.0 and I noticed on first reboot it had already corrected schedule on it's own.

 

 

I'll update in a few days




			
		
Link to comment
Share on other sites

panamajim

Follow-up from my end.
 
My Linux machine has just failed on two recordings.  I've attached the transcode logs and the server log.  From what I could see, the correct recording times for both programs are correctly pulled from the TV guide feed.  The recording appears to fail due to bad incoming data and the recording is stopped.  I took a look at the temporary .ts files and they are the same length as the transcoded files.  That tells me the problem happens prior to the transcoding process, likely when the data is on the network.  My best guess is that the network traffic between the HDHomeRun and the computer is getting dorked.  I think my next step this weekend will be to put a network health monitor on the switch or move the HDHomeRun onto the same switch as the computer (shortening the path between the two).

 

Feedback as to whether my interpretation of the logs is correct would be appreciated.

record-transcode-2a58cf39-ec59-416c-adb9-6838fdb2a922.txt

record-transcode-5e902239-00dc-46c5-9ec5-15c478bc1e89.txt

server-63610662017.zip

Link to comment
Share on other sites

linuxmac

I'm back using the stable Emby version I stopped using the beta version cause I found myself spending way too much time dealing with corky issues. To top it off the last beta version would lock all the tuners of the HDHomerun, I would have to reboot the server to release the tuners :(

 

Well moving on...

 

After a full week of testing I found the issue is linked to the conversion process from ts to mp4. Once the conversion was disabled every show has been recorded in full :)

 

For now I'm using rsync to convert the ts files to mkv and dumping them to the nas and linked the folder so Emby has access to the folder as recordings. For now this is working  ;) 

Link to comment
Share on other sites

panamajim

@@linuxmac, I finally arrived at the same conclusion you did.  Turn off the transcoding and the record to .ts worked fine.  I updated to 3.0.7300.0 and the issue persists on my Linux box.  Looks like I'm going to continue recording to .ts and transcode later.

 

Edit:

Digging into this a bit further, I'm right back to my prior thoughts about the problem being corruption of the incoming video stream.  In transcoding several of the .ts files with ffmpeg from the CLI I find that the .ts streams have bad data in them.  It appears to be dropped frames because In some cases the motion types are bad and in others the ac-text are bad leading to MV errors in P and B frames.

 

I believe the problem lies in one of two areas:  1.)  The computer is having issues recording the .ts file or 2.)  The data is being corrupted on the wire. If the former is the issue then Emby _may_ have a play in this.  If the latter, then I need to fix my network traffic issues.  (This assumes that the HDHomeRun is not the problem.)

 

So, in either case, the original problem that @@linuxmac brought to the table was Emby stopping recording after a period of time.  In my case it seems that the recording was stopping short due to corruption of the .ts stream the large number of resulting errors in the transcoding process.

 

Again, feedback or alternate analysis is appreciated.

Edited by panamajim
Link to comment
Share on other sites

Sorry, the 7300 update was just a surgical bug fix release and does not have the major changes I talked about earlier.

Link to comment
Share on other sites

  • 3 weeks later...
panamajim

Bringing this topic back up because my Linux box situation is degrading slowly.  My Emby distro is now at version 3.0.8200.0 after having performed a fresh re-install with x.8000. and upgrading to x.8100.  Recording to .mp4 and .ts formats now fails at precisely 1.01 minutes for all recordings.  I'm at a loss to understand with clarity why this is and would appreciate any insights.  Attached is the server log.  In as much as anyone is willing to take the time, I'd like to learn the steps to troubleshoot this myself so I don't continue to clog up the forums with repetitive questions.  Thanks all.

 

The most recent record failures were three recordings that fired at 19:59.

server-63612319267.zip

Edited by panamajim
Link to comment
Share on other sites

It looks like you tried to play right at the time of a recording and this may have created a conflict. is that possible?

Link to comment
Share on other sites

Can you provide a log example of one that failed without any playback going on at the time? Obviously it should be OK to play depending on how many tuners you have, but right now it just makes for easier troubleshooting. Thanks.

Link to comment
Share on other sites

panamajim

*facepalm*

 

My apologies Luke, but in the time lapse between my last post and your post I literally blew away my Linux and Emby builds and reinstalled from scratch.

 

I'm going to give it a go and see how well things work after this fresh start.  If it works, I'm _not_ going to dork around with it this time.

 

*note to self....*

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
 Share

×
×
  • Create New...