linuxmac 0 Posted September 18, 2016 Share Posted September 18, 2016 (edited) 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 Edited September 18, 2016 by linuxmac Link to comment Share on other sites More sharing options...
Luke 36887 Posted September 18, 2016 Share Posted September 18, 2016 Hi, we've done some work to address this on the beta channel, if you'd like to try that out. Link to comment Share on other sites More sharing options...
linuxmac 0 Posted September 18, 2016 Author Share Posted September 18, 2016 Will do. I'll update once I test. Link to comment Share on other sites More sharing options...
linuxmac 0 Posted September 18, 2016 Author Share Posted September 18, 2016 Day one follow-up I'm glad to say running Version 3.1.155.0 beta has solved the recordings stopping prematurely. Link to comment Share on other sites More sharing options...
Luke 36887 Posted September 18, 2016 Share Posted September 18, 2016 Thanks for the feedback ! Link to comment Share on other sites More sharing options...
linuxmac 0 Posted September 21, 2016 Author Share Posted September 21, 2016 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 Link to comment Share on other sites More sharing options...
Luke 36887 Posted September 21, 2016 Share Posted September 21, 2016 Ok thanks, I'll take a look. Link to comment Share on other sites More sharing options...
panamajim 5 Posted September 21, 2016 Share Posted September 21, 2016 (edited) 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 September 21, 2016 by panamajim Link to comment Share on other sites More sharing options...
linuxmac 0 Posted September 23, 2016 Author Share Posted September 23, 2016 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 More sharing options...
Luke 36887 Posted September 23, 2016 Share Posted September 23, 2016 Thanks for the feedback. Link to comment Share on other sites More sharing options...
panamajim 5 Posted September 30, 2016 Share Posted September 30, 2016 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 More sharing options...
Luke 36887 Posted September 30, 2016 Share Posted September 30, 2016 Hi, we are actively working on resolving this for the next release, thanks. Link to comment Share on other sites More sharing options...
panamajim 5 Posted September 30, 2016 Share Posted September 30, 2016 Hi, we are actively working on resolving this for the next release, thanks. Gotcha. Thanks for the quick response. Link to comment Share on other sites More sharing options...
linuxmac 0 Posted October 2, 2016 Author Share Posted October 2, 2016 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 More sharing options...
panamajim 5 Posted October 2, 2016 Share Posted October 2, 2016 (edited) @@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 October 2, 2016 by panamajim Link to comment Share on other sites More sharing options...
Luke 36887 Posted October 2, 2016 Share Posted October 2, 2016 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 More sharing options...
panamajim 5 Posted October 18, 2016 Share Posted October 18, 2016 (edited) 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 October 18, 2016 by panamajim Link to comment Share on other sites More sharing options...
Luke 36887 Posted October 18, 2016 Share Posted October 18, 2016 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 More sharing options...
panamajim 5 Posted October 19, 2016 Share Posted October 19, 2016 One of my kids may have tried to do that. Unfortunately, recordings since then have also failed. Link to comment Share on other sites More sharing options...
Luke 36887 Posted October 19, 2016 Share Posted October 19, 2016 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 More sharing options...
panamajim 5 Posted October 19, 2016 Share Posted October 19, 2016 *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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now