Seek not working on recordings

[dougw03 16]

Hello,

 

I am using a HDHomerun Prime and native Live TV support with Emby Server running on Windows 10 PC. I recently updated to 3.1.5 and my recordings are having issues seeking. I get an "unable to seek" error on my android TV and when I try playing the videos in VLC on my PC, the videos also will not seek and go back to where they were prior to me seeking. Are there any workarounds? Since I am having the issue in VLC, I assume it is something wrong with the recording file?

[ebr 16178]

If this is happening playing the file directly with VLC then I would say it is not related to Emby at all, yes.

[ebr 16178]

Oh wait - you said these recordings were created by Emby, correct?

 

In that case I would say let's gather some information about how they were recorded and what is happening when you play them back: How to Report a Problem

 

Thanks.

[maegibbons 1287]

@@dougw03

 

Your timezone appears european/uk but the prime is not available here.  Are you sure it is a prime and not a connect?  There are differences in the encoding options.

 

Krs

 

Mark

[dougw03 16]

@@ebr, yes correct created with Emby. I also have emby set to convert recordings to mkv. This problem only started happening when I upgraded to 3.1.5, issue was not happening with 3.1.4. I will report a problem with your link. In the meantime, is there anyway I can revert back to 3.1.4? This is causing a lot of issues with the TV users in the house.

 

@@maegibbons, I never set my timezone properly when I registered. I am based in US and just updated my profile. I am using the prime.

[dougw03 16]

Oh wait - you said these recordings were created by Emby, correct?

 

In that case I would say let's gather some information about how they were recorded and what is happening when you play them back: How to Report a Problem

 

Thanks.

 

I have configured my recordings directly through the emby app and HDHomeRun Prime. I have no post processing application and only have emby set to convert recordings to MKV for a streaming friendly format. I have preserve original video/audio when converting recordings both enabled. The files get recorded to a local NAS. I only started observing this issue after I upgraded to 3.1.5. I did not change any of these settings between 3.1.4 and 3.1.5. I have Intel Quck Sync configured and FFmpeg is set to use a custom version (the default that comes with emby). I have attached all of the files in the server log. Let me know what other information you need.

ffmpeg-transcode-e1772ed5-b61f-4056-a1d7-aaaa63b98cc1.zip

[Luke 42078]

I have configured my recordings directly through the emby app and HDHomeRun Prime. I have no post processing application and only have emby set to convert recordings to MKV for a streaming friendly format. I have preserve original video/audio when converting recordings both enabled. The files get recorded to a local NAS. I only started observing this issue after I upgraded to 3.1.5. I did not change any of these settings between 3.1.4 and 3.1.5. I have Intel Quck Sync configured and FFmpeg is set to use a custom version (the default that comes with emby). I have attached all of the files in the server log. Let me know what other information you need.

 

Hi @@dougw03, can you discuss a specific example that you'd like us to look at? I'm asking because there's quite a few log files in that zip file. I looked at the first two recording logs and they seem normal to me. Thanks.

[dougw03 16]

Hi @@dougw03, can you discuss a specific example that you'd like us to look at? I'm asking because there's quite a few log files in that zip file. I looked at the first two recording logs and they seem normal to me. Thanks.

Hi @@Luke, forgive my ignorance here but I'm not sure what these logs actually represent. Some of the files are no longer on my NAS because people in the house deleted them after not being able to seek, but this is a systemic issue and happening on every recording. 

 

"record-transcode-87a7ed5e-bc05-49ff-8414-bdbfb8d2cf64.txt" is a log from a file I still have on my server. Let me know if anything looks suspicious

[Luke 42078]

when you click on the recording in the web app, what do you see for media info at the bottom of the page? can you copy and paste that? thanks.

[dougw03 16]

Here you go:

 

Media Info

VideoCodecH264
AVCYes
ProfileHigh
Level32
Resolution1280x720
Aspect ratio16:9
AnamorphicNo
InterlacedNo
Framerate59.94006
Bit depth8 bit
Pixel formatyuv420p
Ref frames4
NAL4

AudioCodecAC3
Layout5.1
Channels6 ch
Bitrate384 kbps
Sample rate48000 Hz
DefaultYes
TitleDolby Digital 5.1 Default

Containermkv

PathZ:\Recorded TV\Series\Baskets\Season 2\Baskets S02E03 Bail.mkv

[Luke 42078]

at the top of the screen does it list a runtime?

[dougw03 16]

Also wanted to add the following information:

 

On Emby Android Mobile App: I get message "unseekable stream" when I try to seek

On Emby Android TV App: I get message "unable to seek"

On VLC (Windows 10): Video will not seek (see post above)

On Emby Windows 10 Theater App (same machine as VLC^): I CAN seek; however, I cannot resume. 

 

Not sure if this helps but it seems the theater app can at least seek.

[dougw03 16]

at the top of the screen does it list a runtime?

 

No, but it does on recordings made with Emby Server 3.1.4

[Luke 42078]

That is coincidental, sorry. The recording process is the same between the two releases. As a test, can you try running a library scan? Let me know if that fills in the runtime. thanks.

[dougw03 16]

That is coincidental, sorry. The recording process is the same between the two releases. As a test, can you try running a library scan? Let me know if that fills in the runtime. thanks.

Ran a library scan and still don't see runtime on recordings post-3.1.5 update

[Luke 42078]

As a test, can you manually start a new recording, then cancel it after a few minutes? once cancelled, navigate into it and see if it shows a runtime. thanks.

[dougw03 16]

As a test, can you manually start a new recording, then cancel it after a few minutes? once cancelled, navigate into it and see if it shows a runtime. thanks.

 

I did a 2 minute recording and it worked perfectly fine. I can seek in VLC and can see the runtime...Could it be my recording database got corrupted?

[Luke 42078]

No, nothing database related. It is something related to the recording file and the evidence is the problem in Vlc.  The most likely culprit is that the recordings were terminated abruptly for some reason rather than allowing them to gracefully stop. That usually results in a damaged file that most players will have trouble with. Is it possible you may have abruptly shut down or restarted the server during a recording?

[dougw03 16]

No, nothing database related. It is something related to the recording file and the evidence is the problem in Vlc.  The most likely culprit is that the recordings were terminated abruptly for some reason rather than allowing them to gracefully stop. That usually results in a damaged file that most players will have trouble with. Is it possible you may have abruptly shut down or restarted the server during a recording?

 

Seems very unlikely since this has happened on every recording (around 6 recordings) since I updated my server. These are all series recordings too and none were done manually. 

[dougw03 16]

@@Luke @@ebr do you guys have any other suggestions? I tried a new series recording and used the PC the whole time while the recording was happening to make sure nothing shut down or restarted the server and the recording is showing up as damaged. This is only happening on series recordings...manual recordings have no issues. Any help would be much appreciated!

 

Edit: Also tried this after upgrading to 3.2.0 and problem still persists.

Edited February 7, 2017 by dougw03

[Guest asrequested]

Have you tried converting to MP4 or not converting at all?

[dougw03 16]

Have you tried converting to MP4 or not converting at all?

@, thank you for your suggestion. I changed to not converting at all and the problem has gone away.

 

@@Luke @@ebr, can you see if it's possible to replicate this bug? It only occurs on series recordings on 3.1.5 and above with mkv conversion on recordings from HDHomeRun Prime.

[Guest asrequested]

To help Luke, you may want to turn on conversion, make a test recording, and post that specific transcode log. If you don't know which log that is, sort them by time, and you'll be able to see it.

[Luke 42078]

hi @@dougw03, I know you have previously provided logs, but let's start from the beginning and look at this with the latest version of the server. Can you please attach the server log and recording log (if present), from a recording?

 

Also, just for my own information, did this include any playback of in-progress recording, or was the recording completely untouched until completion? Thanks !

[dougw03 16]

@@Luke will do. I've got some recordings starting soon and will hold off until tomorrow. By the way, I did try using MP4 instead of MKV and this setting also doesn't exhibit the seek issue and seems to only be a series recording on mkv. I'll post back as soon as I have some results. Thanks again