no compatible streams on playback of tvheadend recordings

[vaise 307]

The roku's say 'ignored'

The web chrome say 'no campatable streams.

beta version - latest.  Emby docker.

 

I can play the file on the compuiter fine - the wife non to happy to have to crowd around the screen.  After many years of windows and nextPVR never missing a beat she is not pleased...... and I am in trouble for 'fixing somethng not broken'.   gggggrrrr

 

This is on three recordings so far.

 

The emby logs state this - an ffmpeg issue :

 

2018-08-02 19:43:30.864 Info App: /bin/ffmpeg -i file:"/mnt/user/Recordings/You Can't Ask That/You Can't Ask That - 2018-08-01.ts" -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 libx264 -vf "yadif=0:-1:0" -pix_fmt yuv420p -preset veryfast -crf 23 -maxrate 3290482 -bufsize 6580964 -profile:v high -level 4.1 -x264opts:0 subme=0:me_range=4:rc_lookahead=10:me=dia:no_chroma_me:8x8dct=0:partitions=none -force_key_frames "expr:if(isnan(prev_forced_t),eq(t,t),gte(t,prev_forced_t+3))" -copyts -vsync -1 -codec:a:0 libmp3lame -ac 2 -ab 256000  -f segment -max_delay 5000000 -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 -start_at_zero -segment_time 3  -individual_header_trailer 0 -segment_format mpegts -segment_list_type m3u8 -segment_start_number 0 -segment_list "/config/transcoding-temp/181e601f4331c77641edc4fd49fb1630.m3u8" -y "/config/transcoding-temp/181e601f4331c77641edc4fd49fb1630%d.ts"

2018-08-02 19:43:31.017 Error HttpServer: Error processing request

*** Error Report ***

Version: 3.6.0.2

Command line: /system/EmbyServer.dll -programdata /config -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3

Operating system: Unix 4.14.49.0

64-Bit OS: True

64-Bit Process: True

User Interactive: True

Processor count: 8

Program data path: /config

Application directory: /system

System.Exception: Error starting ffmpeg

   at Emby.Server.MediaEncoding.Api.BaseStreamingService.StartFfMpeg(StreamState state, String outputPath, EncodingOptions encodingOptions, CancellationTokenSource cancellationTokenSource, Boolean acquireResources)

   at Emby.Server.MediaEncoding.Api.BaseStreamingService.StartFfMpeg(StreamState state, String outputPath, EncodingOptions encodingOptions, CancellationTokenSource cancellationTokenSource, Boolean acquireResources)

   at Emby.Server.MediaEncoding.Api.Hls.DynamicHlsService.GetDynamicSegment(StreamRequest request, String segmentId)

   at Emby.Server.Implementations.Services.ServiceExecGeneral.GetTaskResult(Task task)

   at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost appHost, IRequest httpReq, IResponse httpRes, ILogger logger, String operationName, CancellationToken cancellationToken)

   at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IHttpRequest httpReq, String urlString, String host, String localPath, CancellationToken cancellationToken)

System.Exception

   at Emby.Server.MediaEncoding.Api.BaseStreamingService.StartFfMpeg(StreamState state, String outputPath, EncodingOptions encodingOptions, CancellationTokenSource cancellationTokenSource, Boolean acquireResources)

   at Emby.Server.MediaEncoding.Api.BaseStreamingService.StartFfMpeg(StreamState state, String outputPath, EncodingOptions encodingOptions, CancellationTokenSource cancellationTokenSource, Boolean acquireResources)

   at Emby.Server.MediaEncoding.Api.Hls.DynamicHlsService.GetDynamicSegment(StreamRequest request, String segmentId)

   at Emby.Server.Implementations.Services.ServiceExecGeneral.GetTaskResult(Task task)

   at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost appHost, IRequest httpReq, IResponse httpRes, ILogger logger, String operationName, CancellationToken cancellationToken)

   at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IHttpRequest httpReq, String urlString, String host, String localPath, CancellationToken cancellationToken)

 

2018-08-02 19:43:31.017 Info HttpServer: HTTP Response 500 to 192.168.1.10. Time: 244ms. http://192.168.1.7:8096/emby/videos/682dc2f7d099f95528e20e34f7d3e09d/hls1/main/0.ts?DeviceId=TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzY3LjAuMzM5Ni45OSBTYWZhcmkvNTM3LjM2fDE1MzMxOTU4NTMxOTY1&MediaSourceId=682dc2f7d099f95528e20e34f7d3e09d&VideoCodec=h264&AudioCodec=mp3,aac&AudioStreamIndex=1&VideoBitrate=139744000&AudioBitrate=256000&PlaySessionId=3ada73b908444212ba9d819aa5c8943e&SubtitleMethod=Encode&TranscodingMaxAudioChannels=2&Tag=bb8209a0c05c702bb7c162445dd51f91&SegmentContainer=ts&MinSegments=1&BreakOnNonKeyFrames=True&h264-profile=high,main,baseline,constrainedbaseline,high10&h264-level=51&TranscodeReasons=ContainerNotSupported,VideoCodecNotSupported,AudioCodecNotSupported&allowVideoStreamCopy=false&allowAudioStreamCopy=false 

 

Full log is attached.

 

'The weekly' was another show, and 'The Last Leg' was the third.

 

Any ideas ?

 

embyserver.txt

[vaise 307]

More info - I fired up my windows emby server - it is reading the same files, and it can play these fine.

 

This must be a linux/docker/ffmpeg issue therefore ?

 

The windows server is on a machine that is shutdown - it is named 'Emergency use only' - I did not expect i would have to use it for this sort of thing.

 

One thing - in case it helps - the windows server is one release behind - 3.5.1 rather than 3.5.2.'

 

Thanks,

[Luke 37095]

it appears Emby Server doesn't have read access to your files. Notice all the errors in your server log along those lines:

2018-08-02 18:54:32.852 Error App: Error validating images for /mnt/user/Media/Media3D/Avatar 3D (2009)/Avatar 3D.mkv
	*** Error Report ***
	Version: 3.6.0.2
	Command line: /system/EmbyServer.dll -programdata /config -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
	Operating system: Unix 4.14.49.0
	64-Bit OS: True
	64-Bit Process: True
	User Interactive: True
	Processor count: 8
	Program data path: /config
	Application directory: /system
	System.IO.DirectoryNotFoundException: Could not find a part of the path '/mnt/user/Media/Media3D/Avatar 3D (2009)'.

[vaise 307]

OK, I can fix that - but that is not relating to the recordings is it ?

[Luke 37095]

Yes it appears it is.

[vaise 307]

OK - I am running docker safe new permissions utility over unraid, which should resolve any files permissions issues I believe.

I will then restart emby to get clean logs and report back

 

I want to say I am not overly optimistic here on this fix however as it has passed the recordings folder and the issue remains.

Further, it has been fine all week, other recordings before that were fine, and after that were fine.

Is it coincidental that the failures are from the same TV channel (ABCHD in australia) ?

[Luke 37095]

Everything I've seen so far looks permissions related.

[vaise 307]

That 3dmedia is now 3dmovies - renamed but not updfated in the docker when backup/restore done - little used so not noticed.  I will edit the library so those issues are gone - that is NOT permissions issue and has been there from day 1 of the new docker so i dont see how it relates to an issue that just started in last 2 days..

[Luke 37095]

You didn't mention that until after i had given an answer, so yes, you're right, that's not permissions related. 

[vaise 307]

Yep - sorry.

 

OK - starting again clean.  Docker safe permissions run anyway.

Fixed up the media3d

restarted emby

 

fired up roku, played each of the three bad things one after another

then played a working thing

 

Log attached (and all three play from emby in windows), plus on PC, streamed from TVH to laptop also ok.

 

 

 

 

embyserver.txt

[Luke 37095]

And what happened with each?

[vaise 307]

as per first post - ignored if played on the roku,, im sure if i try from chrome,  'no campatable streams.

 

Maybe these transcode things may offer something ?  They all appeared at the same time as the above tests - strangely 7 of them, so i assume the failed one creates two, and the working one created 1 ?

ffmpeg-remux-1e239bf0-28f0-4b90-8ed9-85b4926e2864.txt

ffmpeg-remux-2f2688c7-cd3e-4b32-b8f3-269313b2da30.txt

ffmpeg-remux-11fa5942-b29d-4566-a8b2-226e6db06d05.txt

ffmpeg-remux-5516fa71-63c3-45c8-ac67-cffa84a46c0e.txt

ffmpeg-remux-c5b2d0e1-0631-4d50-81b1-e89a12f82f28.txt

ffmpeg-remux-c606020e-a499-4ea3-9fd9-f2e8ea21f4fc.txt

ffmpeg-remux-e3a25fb7-92b7-4314-a34b-d34736f4d620.txt

[vaise 307]

I have kicked off a few recordings from the same channel..... for kicks...... in case if is the stream from that channel and the ffmpeg update (if any) in 3.6.2.  Unfortunately, a few hours before they complete (one I kicked of half way so in 20 mins i may be able to play that one.

Will report back.

[vaise 307]

I think I am onto a winner here.

A recording from that same channel i just made has the SAME ISSUE.

And note - previous recordings before this latest beta release were fine.

 

Is there any other linux users, (I am specifically using docker), that are in australia and can test a HD Homerun recording from ABC HD ?

That is a pretty big ask I imagine.......

 

There is another recording expected to complete in 30 minutes that should prove this beyond a shadow of a doubt ?

 

I think you need to look into any recent ffmpeg changes ?

 

V.

Edited August 2, 2018 by vaise

[vaise 307]

I can confirm - I cannot play back ANY recordings from the Australian TV Broadcaster Channel ABC HD in Australia on the latest Beta on linux (docker) version 3.6.2.

They play back fine on windows emby (3.6.1) .

 

That broadcaster has a few other channels on their mux - I will try a few of the others - they are not HD however.

[vaise 307]

Hi,

 

OK - proven an entire broadcaster's mux in australia cannot be played on 3.6.0.2 docker.

This is the Australian Broadcaster ABC - I tried ABCHD, ABC Kids and ABCME channels - all have the same ffmpeg error in the logs

 

I dont know what else i can do to test....

 

V.

[vaise 307]

Any fix likely for this ?  

Any more info i can provide to assist ?

[vaise 307]

My final bit of testing (and a nail in the coffin for use in Australia on docker - or linux, not sure which) :

 

I installed the normal production release of the docker, just added the recorded TV folder only.

Tried to play back these recordings from The ABC channel.

They do not play - same ffmpeg error on all.

All other networks recordings are fine.

 

And Emby for windows plays these fine.

 

What more can I do ?

[vaise 307]

Adding the logs from this brand new install of docker - non beta.
 

Note - the latest here shows a working playback also (hence the same 7 logs as before)

 

 

embyserver.txt

embyserver-63669003820.txt

ffmpeg-remux-0ed85c43-2492-494e-968c-dd1c56fc8c7a.txt

ffmpeg-remux-1e8b2e9d-eb00-4f52-a4e7-51e75245ba82.txt

ffmpeg-remux-a9c60fde-2662-426a-b686-5dded74ee9b3.txt

ffmpeg-remux-ac98acd1-15b5-4b42-9c25-bba07354c985.txt

ffmpeg-remux-cf2bc3a2-c7d6-4e33-b1cb-4c52162e4b99.txt

ffmpeg-remux-e0837f79-5633-4e15-8bce-e740d057d5a3.txt

ffmpeg-remux-f1440a4e-3135-4472-ac88-e0e76ee870a3.txt

[vaise 307]

I noticed there were dlna errors and address in use errors on those logs - as this was an extra server added just for this test - so I have stopped dlna and restarted to get clean logs, and tried this again.

 

A better log attached showing just the issue.

 

Look at 18:48:55 for the actual ffmpeg issue.

 

 

embyserver.txt

ffmpeg-remux-32754197-cc8e-42e7-a0c3-a3be8fdfdb6d.txt

ffmpeg-remux-df7368ee-ae3c-46ab-8926-c4aae32c846b.txt

[vaise 307]

Update - this is all fixed now.

I think alucryd did something to fix it.