Emby blackscreen \ stops playing

[AciDCooL 7]

Hi,

 

I'm having this issues for a while now, and users reporting this to me, can't be sure when it started though. But is seems to me that transcoding errors out somewhere and doesnt get picked up gain, even with pause / start. Which makes sense cause if Emby would start a thread every time someone pause/played the server could go bananas.

So when this issue happens the web player just stops and gives a blackscreen. Play/pause nothing works, back button works and playing the file again works, sometimes emby knows where we left of but most of the times it start of at the beginning of the file again. **sidenote: some users are using emby theater and they have no issues, although maybe they didn't report them yet.. unsure if this is completely true now I think of it.

I attached the logs and it happened here around 2020-12-22 00:09:33 on my webplayer.

emby failure.zip

[AciDCooL 7]

Ok today another black screen @ 15:30. This time a snippet of the embyserver log since it was huge

emby failure 1530.zip

[Luke 42078]

Hi there, please try updating to 4.5.4 and see if that helps. thanks.

[AciDCooL 7]

Updated yesterday to 4.5.4, but some problem came up today.

And it looks like it is about the same time, mostly at the end of a file didn't check the exact time last few black screen but now it was around 45minutes playtime. 

 

Problem in the logs @ 14:18~

 

14:18:31.892 SegmentComplete=video:0 Index=470 Start=2820.026000 End=2826.031689 Duration=6.005689 offset_pts=0 start_pts=2820026000 Frames=146 filename=88642A_470.ts
14:18:31.892 [segment @ 0x1fa9180] Opening '/localmedia/EmbyStuff/EmbyTranscode/transcoding-temp/88642A_471.ts.tmp' for writing
14:18:31.892 [segment @ 0x1fa9180] Failed to open segment '/localmedia/EmbyStuff/EmbyTranscode/transcoding-temp/88642A_471.ts.tmp'
14:18:31.893 av_interleaved_write_frame(): Structure needs cleaning
14:18:31.894 14:18:31.894 Error writing trailer of /localmedia/EmbyStuff/EmbyTranscode/transcoding-temp/88642A_%d.ts: Invalid argument
14:18:31.894 frame=67759 fps=5.5 q=-1.0 Lsize= 2244880kB time=00:47:05.99 bitrate=6535.9kbits/s throttle=off speed=0.229x    
14:18:31.894 video:2178646kB audio:66234kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
    Last message repeated 1 times
14:18:31.894 EXIT
14:18:31.907 Conversion failed!
14:18:31.907 

 

Emby Failure 1418.zip

[Q-Droid 989]

Are you running out of space on that path?

 

[AciDCooL 7]

58 minutes ago, Q-Droid said:

Are you running out of space on that path?

 

Nah not even close, have 85Gigs of free space, PRTG monitoring showing its filling up for about 15 to 20G So worst case I have 50G of free space on a given moment.

[AciDCooL 7]

Ok I might have found a discrepancy, I looked at the files in transcoding temp and noticed two really old files, when I tried to remove them the server refused. And "ls -alh" showed me two files saying "no such file or directory". This was reason to believe that there was corruption, I pulled out fsck -n (on a mounted system I know get your pitchforks ready) And showed me allot of wierd stuff on that disk, so I decided to repair it while offline. Offlined my rancher instance to recovery mode and ran fsck, which took a long time and repaired allot of inodes folders etc.

Now everything is back online, i'll keep testing, if it happens again I think just to be sure i'll make a new mount on my ssd array to exclude this completely.

[Luke 42078]

@AciDCooL are you still having an issue with this?

[AciDCooL 7]

Hi @Luke no sorry ik in the middle of holiday madness, and birthday of my son and myself. So for the first time this year haven't had time to watch anything. And no users reported anything but the that doesn't say much. I'll put in an extra morning work out and watch a episode or two, I'll keep you posted.

[AciDCooL 7]

@LukeI've watched multiple episodes even the ones that got stuck and I think it's safe to say that it is fixed now. Not sure if it was the disk or the version, or combination of the two. Ill spin up a second docker swarm node with different hardware next time around to ensure it's not hw related.

Good thing that came from this is that I now checked all my vdisks and found some more errors one other vm's, server had a cpu crash 2 months ago apparently corrupted some vdisks. 

[Luke 42078]

Thanks for the feedback.