Conversion Error

[tcjones5305 2]

I have enabled conversions for my recorded TV, some of them complete successfully, but most seem to fail.
I can't determine why, it seems like even the same show on the same channel sometimes complete and sometimes fail.
Attached are a couple conversions that failed.

Does anyone have any ideas what is causing this error?

03:38:14.832 Error while filtering: Device or resource busy
03:38:14.832 Failed to inject frame into filter network: Device or resource busy
03:38:14.832 Error while processing the decoded data for stream #0:0
03:38:14.910 [aac @ 0000007930812940] Qavg: 663.588
03:38:14.910 [aac @ 0000007930812940] 2 frames left in the queue on closing
03:38:14.910 [aac @ 0000007930810980] Qavg: 151.563
03:38:14.910 [aac @ 0000007930810980] 2 frames left in the queue on closing
03:38:14.910 [aac @ 0000007930810e00] Qavg: 60952.551
03:38:14.910 [aac @ 0000007930810e00] 2 frames left in the queue on closing
03:38:14.910 Conversion failed!

ffmpeg-transcode-7ec361b5-cd70-43b8-8e43-4ca406be90ee_1.txt ffmpeg-transcode-3bf0da35-a13f-444e-b584-0fe143ee6bda_1.txt

[Carlo 4561]

@softworkzwould likely need to comment but it could be faulty streams that cause a problem.

[tcjones5305 2]

I am also getting some of these errors:

12:41:31.439 frame= 6365 fps= 30 q=0.0 size=       0kB time=-577014:32:22.77 bitrate=N/A dup=385 drop=0 throttle=off speed=   0x    
12:41:31.865 Too many packets buffered for output stream 0:2.
12:41:31.917 [libx264 @ 0000005d5e398400] frame I:36    Avg QP:17.21  size: 23552
12:41:31.917 [libx264 @ 0000005d5e398400] frame P:2152  Avg QP:22.23  size:  4408
12:41:31.917 [libx264 @ 0000005d5e398400] frame B:4169  Avg QP:26.18  size:   686
12:41:31.917 [libx264 @ 0000005d5e398400] consecutive B-frames:  7.1% 13.8%  7.7% 71.4%
12:41:31.917 [libx264 @ 0000005d5e398400] mb I  I16..4: 35.9% 24.8% 39.3%
12:41:31.917 [libx264 @ 0000005d5e398400] mb P  I16..4: 12.1%  0.0%  0.0%  P16..4: 25.3%  0.0%  0.0%  0.0%  0.0%    skip:62.7%
12:41:31.917 [libx264 @ 0000005d5e398400] mb B  I16..4:  0.7%  0.0%  0.0%  B16..8:  6.1%  0.0%  0.0%  direct: 3.1%  skip:90.1%  L0:41.3% L1:45.1% BI:13.6%
12:41:31.917 [libx264 @ 0000005d5e398400] 8x8 transform intra:2.7% inter:32.9%
12:41:31.917 [libx264 @ 0000005d5e398400] coded y,uvDC,uvAC intra: 34.3% 46.6% 25.3% inter: 4.3% 6.5% 1.0%
12:41:31.917 [libx264 @ 0000005d5e398400] i16 v,h,dc,p: 56% 21% 11% 11%
12:41:31.917 [libx264 @ 0000005d5e398400] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 18% 18%  8%  7%  7%  7%  8%  9%
12:41:31.918 [libx264 @ 0000005d5e398400] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 18% 10%  8%  7%  7%  6%  7%  7%
12:41:31.918 [libx264 @ 0000005d5e398400] i8c dc,h,v,p: 48% 20% 25%  7%
12:41:31.918 [libx264 @ 0000005d5e398400] Weighted P-Frames: Y:3.1% UV:2.2%
12:41:31.918 [libx264 @ 0000005d5e398400] kb/s:497.54
12:41:31.940 [aac @ 0000005d5e15bec0] Qavg: 1278.008
12:41:31.941 [aac @ 0000005d5e15bec0] 2 frames left in the queue on closing
12:41:31.951 [aac @ 0000005d5e159ec0] Qavg: 9226.343
12:41:31.952 [aac @ 0000005d5e159ec0] 2 frames left in the queue on closing
12:41:31.977 Conversion failed!
12:41:31.977

 

Does anyone know what might be causing these errors?

ffmpeg-transcode-51d85121-9a9b-4085-bf94-c0797bfbed36_1.txt

[tcjones5305 2]

Coincidentally, Handbrake also fails when I try to convert these files.
Attached are the logs from Handbrake.
Based on the Handbrake log, I thought maybe it was characters in the file name or a permissions error, but that doesn't appear to be the problem either.

[10:40:27] mpeg2video: "Chapter 1" (1) at frame 0 time 9009
x264 [info]: profile Main, level 4.0
ERROR: avio_open2 failed, errno -13
[10:40:27] work: average encoding speed for job is 0.000000 fps
[10:40:27] sync: first pts is 9009
[10:40:27] sync: got 1 frames, 64133 expected
[10:40:28] render: lost time: 0 (0 frames)
[10:40:28] render: gained time: 0 (0 frames) (0 not accounted for)
[10:40:28] mpeg2video-decoder done: 10 frames, 0 decoder errors, 0 drops
[10:40:28] reader: done. 1 scr changes
[10:40:28] ac3-decoder done: 0 frames, 0 decoder errors, 0 drops
[10:40:28] stream: 80 good frames, 0 errors (0%)
[10:40:28] libhb: work result = 3
Encode failed (error 3).
HandBrake has exited.

 

Does anyone have any suggestions for something to try to resolve these converting problems?

last_scan_log1116.txt last_encode_log1116.txt

[Carlo 4561]

Hi, have you tried running these files through a tool such as MKV Fix or similar?

[Luke 42078]

Yea this looks like a problem with the file to me.

[tcjones5305 2]

Can you provide a link for MKV Fix?
I am not familiar with that program.

[Luke 42078]

7 minutes ago, tcjones5305 said:

Can you provide a link for MKV Fix?
I am not familiar with that program.

I would suggest running it through mkvtoolnix.

[tcjones5305 2]

What am I looking for mkvtoolnix to do?
I run mkvtoolnix and have it convert the .ts file that Emby created from DVR, and it produces a .mkv file
It has a warning of "Found at least one B frame without second reference in a non closed GOP", other than that, it all appears to be fine.

Handbrake will convert the .mkv file to a .mp4 file.
As I mentioned earlier, Handbrake will not convert the .ts file to .mp4.

Emby will play the .ts file, the .mkv file, and the .mp4 file.
Also, VLC will play the .mkv file, the .ts file, and the .mp4 file.
What does this tell me?
Why won't Emby Convert convert the file?

Ideally I am looking for Emby to DVR directly into a file format that Roku Ultimate can direct stream.
That seems like a future enhancement.
As a secondary choice, I would like Emby to convert the .ts file that it records to a format that Roku can direct stream.
So far, Emby only successfully converts like 10% of the files it records.

Some of the Emby Conversions have this error:
20:13:29.227 Too many packets buffered for output stream 0:2.
20:13:29.274 [libx264 @ 00000039f1568400] frame I:36    Avg QP:17.21  size: 23552
20:13:29.290 [libx264 @ 00000039f1568400] frame P:2152  Avg QP:22.23  size:  4408
20:13:29.290 [libx264 @ 00000039f1568400] frame B:4169  Avg QP:26.18  size:   686
20:13:29.290 [libx264 @ 00000039f1568400] consecutive B-frames:  7.1% 13.8%  7.7% 71.4%
20:13:29.290 [libx264 @ 00000039f1568400] mb I  I16..4: 35.9% 24.8% 39.3%
20:13:29.290 [libx264 @ 00000039f1568400] mb P  I16..4: 12.1%  0.0%  0.0%  P16..4: 25.3%  0.0%  0.0%  0.0%  0.0%    skip:62.7%
20:13:29.290 [libx264 @ 00000039f1568400] mb B  I16..4:  0.7%  0.0%  0.0%  B16..8:  6.1%  0.0%  0.0%  direct: 3.1%  skip:90.1%  L0:41.3% L1:45.1% BI:13.6%
20:13:29.290 [libx264 @ 00000039f1568400] 8x8 transform intra:2.7% inter:32.9%
20:13:29.290 [libx264 @ 00000039f1568400] coded y,uvDC,uvAC intra: 34.3% 46.6% 25.3% inter: 4.3% 6.5% 1.0%
20:13:29.290 [libx264 @ 00000039f1568400] i16 v,h,dc,p: 56% 21% 11% 11%
20:13:29.290 [libx264 @ 00000039f1568400] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 18% 18%  8%  7%  7%  7%  8%  9%
20:13:29.290 [libx264 @ 00000039f1568400] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 18% 10%  8%  7%  7%  6%  7%  7%
20:13:29.290 [libx264 @ 00000039f1568400] i8c dc,h,v,p: 48% 20% 25%  7%
20:13:29.290 [libx264 @ 00000039f1568400] Weighted P-Frames: Y:3.1% UV:2.2%
20:13:29.290 [libx264 @ 00000039f1568400] kb/s:497.54
20:13:29.305 [aac @ 00000039f132ba00] Qavg: 1278.008
20:13:29.305 [aac @ 00000039f132ba00] 2 frames left in the queue on closing
20:13:29.321 [aac @ 00000039f132d580] Qavg: 9226.343
20:13:29.321 [aac @ 00000039f132d580] 2 frames left in the queue on closing
20:13:29.336 Conversion failed!
20:13:29.336

Does any one have any suggestions on how to get Emby Conversions to work all the time?

Thanks,
Terry

[Luke 42078]

@softworkz will take a look at this. Thanks.

[softworkz 5066]

@tcjones5305 - Looks in fact like issues in the recorded files. Do you apply any post-processing to the recordings?

[tcjones5305 2]

No post-processing, files are how Emby records them.

[softworkz 5066]

What's the tv source/tuner?

[tcjones5305 2]

HDHomeRun CONNECT QUATRO with over-the-air TV.

[softworkz 5066]

Could you try to make a recording directly from the tuner?

Then we could see whether it's due to something that Emby does.

[tcjones5305 2]

I’m not sure how to do that.
Can I record it with VLC somehow?

[softworkz 5066]

I think you can simply click a channel in the channels list of the HDHR's web UI.

@cayars - right?

[Carlo 4561]

That will start playing but won't stop. Instead do this:

http://192.168.100.22:5004/auto/v3&duration=60
This will record channel 3 for 60 seconds from my tuner on IP 192.168.100.22

Change the IP to point to your HDHomeRun
Change the number after the "v" to be the channel number
Change the last number to be number of seconds to record

[tcjones5305 2]

I did the url for the channels that I know I am having trouble with (I might have trouble with every channel, I haven't determined a pattern yet).
It created .mpeg files.
I was able to convert the .mpeg files to .mp4 files using Handbrake.
Does this tell me that my tuner is good?

Attached is another log file where the Emby conversion tries and fails, then tries something different (software transcoding?) which works for a while then fails.

17:35:01.798 Too many packets buffered for output stream 0:2.

Does anyone have suggestions to resolve this error?

I am running Emby Portable on Windows 8.1 Pro 64-bit, 16GB RAM.
My processor is a Intel Celeron N3150 1.60 GHz.
Intel HD Graphics display adapter.
Maybe one of these items has something to do with my problems?

ffmpeg-transcode-06842fe4-be5a-4064-9855-b9384e9c4ec9_1.txt

[Carlo 4561]

I see 17:31:21.986 [mpeg2video @ 0000005adadd8ec0] Invalid frame dimensions 0x0.

repeated 44 times or so.

Are you able to play this file in Emby? Do you get proper video?

[softworkz 5066]

5 hours ago, tcjones5305 said:

Attached is another log file where the Emby conversion tries and fails, then tries something different (software transcoding?) which works for a while then fails.

But that log file is not from a manual recording like I asked you to do, right?

[Carlo 4561]

He sort of did it but then convoluted it.

The mpeg files would have been direct downloads from the tuners but then he converted them (not sure why) which stopped the test dead in the water.

The mpeg files are just TS files.

[Carlo 4561]

I hope this doesn't get in the way of support that softworkz is trying to give you but let me ask you this.

Is there any show that always fails conversion?

If so we can setup a recording in Emby and a manual capture/"recording" with the URL capture technique of the same show.
Then we could run back to back test of the convert.

Would this be of help softworkz?

[softworkz 5066]

8 minutes ago, cayars said:

He sort of did it but then convoluted it.

To me it looks like he did it, but then posted another logfile from a normal recording done by Emby:

6 hours ago, tcjones5305 said:

Attached is another log file where the Emby conversion tries and fails, then tries something different (software transcoding?) which works for a while then fails.

...

2 minutes ago, cayars said:

Is there any show that always fails conversion?

He said he doesn't know whether it's specific to a certain channel (or show):

6 hours ago, tcjones5305 said:

the channels that I know I am having trouble with (I might have trouble with every channel, I haven't determined a pattern yet).

 

-----------------

The purpose of the current experiment is pretty simple: 

We want to find out whether the conversion issues are caused by something in the broadcast streams or by something that Emby does to the data when recording.

That means that it doesn't help to see additional log files documenting the original issue. We need to perform a number of manual recordings (without Emby) and then move those into Emby manually in order to compare the results to those recordings made by Emby directly. (whether Handbrake likes those recordings or not, is surely interesting but only secondary information).

An unfortunate inconvenience: as the failure is reported to happen only sometimes but not always, it won't be sufficient to do just a single test-recording. We'll need to do at least a couple of those "manual recordings" in order to get representative results.

[Carlo 4561]

I too agree with that for diagnostic purposes.

If need be I could assist via remote with some tests if this would help.