Recorded show reporting too long of a duration

[pcm2a 9]

I scheduled a 1 hour show to record with 3 minutes before and 4 minutes after. After the show finished what I ended up with was a mess. My Emby server is a Synology DS216+ running 4.1.0.10 beta. The file size is 2.2 gigs.

 

- In Roku Emby it says the show is 4 hours. It start playing but if you try to skip forward then it never resumes

- In Android Emby it says the show is around 24 hours. It starts playing but you cannot skip forward

- In Web Emby it says the show is also around 24 hours, same issue as the android app

- In VLC the file plays and seems the correct length but the time in the scrubber always shows 0:00

 

I opened up the shows .nfo file and I see the following which I assume is what's causing the 24 hour number:

<duration>1497</duration>

 

 

<programme start="20190305020000 +0000" stop="20190305030000 +0000" channel="CBSWCBS.us">
    <title lang="en">Magnum P.I</title>
    <sub-title lang="en">Black is the Widow</sub-title>
    <desc lang="en">After a man is murdered, Magnum poses as a doctor on the same dating app the victim was using in order to find the killer, who may be praying on wealthy men</desc>
    <episode-num system="xmltv_ns">0.15.</episode-num>
    <premiere/>
    <subtitles/>
    <rating system="US">
      <value>TV14</value>
    </rating>
  </programme>

Edited March 5, 2019 by pcm2a

[Luke 38863]

We've seen this occasionally with some recordings and we are looking into it. Thanks.

[pcm2a 9]

I had this happen again and with a suggestion from someone else I tried this command:

ffmpeg -i original.ts -c copy output.ts

I deleted the original after, renamed the output to the original, rescanned and the time was fixed! The time showed up right and scrubbing worked.

[Luke 38863]

Thanks, we are still looking into it.

[pcm2a 9]

Any updates on this? I am getting it at least once a week out of maybe 15 recordings. I'm now testing out post processing scripts to fix the issue. Does the output from a post processing script show up in the emby logs?

 

Script: /usr/bin/emby_post_processing.sh

#!/bin/bash
ffmpeg -i "$1" 2>&1 | grep Duration
ffmpeg -i "$1" -c copy "$1.ts"
mv "$1.ts" "$1"
ffmpeg -i "$1" 2>&1 | grep Duration

Before this is what it shows:

 

 

After a library scan this is what it shows:

 

 

Output from the script with some extra lines removed:

  Duration: 21:27:56.58, start: 19330.216367, bitrate: 208 kb/s
ffmpeg version 2.7.1 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.9.3 (crosstool-NG 1.20.0) 20150311 (prerelease)
  configuration: --prefix=/usr --incdir='${prefix}/include/ffmpeg' --arch=i686 --target-os=linux --cross-prefix=/usr/local/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- --enable-cross-compile --enable-optimizations --enable-pic --enable-gpl --enable-shared --disable-static --enable-version3 --enable-nonfree --enable-libfaac --enable-encoders --enable-pthreads --disable-bzlib --disable-protocol=rtp --disable-muxer=image2 --disable-muxer=image2pipe --disable-swscale-alpha --disable-ffserver --disable-ffplay --disable-devices --disable-bzlib --disable-altivec --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libmp3lame --disable-vaapi --disable-decoder=amrnb --disable-decoder=ac3 --disable-decoder=ac3_fixed --disable-encoder=zmbv --disable-encoder=dca --disable-encoder=ac3 --disable-encoder=ac3_fixed --disable-encoder=eac3 --disable-decoder=dca --disable-decoder=eac3 --disable-decoder=truehd --cc=/usr/local/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ccache-gcc --enable-yasm --enable-libx264 --enable-encoder=libx264
  libavutil      54. 27.100 / 54. 27.100
  libavcodec     56. 41.100 / 56. 41.100
  libavformat    56. 36.100 / 56. 36.100
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 16.101 /  5. 16.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.100 /  1.  2.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mpegts, from '/volume1/storage/Recordings/The Blacklist/Season 6/temp/The Blacklist S06E15 Olivia Olson.ts':
  Duration: 21:27:56.58, start: 19330.216367, bitrate: 208 kb/s
  Program 1
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
    Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 127 kb/s
Output #0, mpegts, to '/volume1/storage/Recordings/The Blacklist/Season 6/temp/The Blacklist S06E15 Olivia Olson.ts.ts':
  Metadata:
    encoder         : Lavf56.36.100
    Stream #0:0: Video: h264 ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 59.94 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, 127 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
.... left out a bunch of lines here...
frame=187426 fps=4929 q=-1.0 Lsize= 1969960kB time=01:07:34.47 bitrate=3980.3kbits/s
video:1740399kB audio:63889kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 9.182084%
  Duration: 01:07:34.60, start: 1.405467, bitrate: 3980 kb/s

On my Synology DS216 it processed about 1 minute of video each second.

[Luke 38863]

We are still looking into this, thanks.

[tmurphy2792 18]

Is this still a known issue being investigated?

I found this post while searching for solutions to the problem I'm having. It appears I'm experiencing basically the same thing as OP.

So far I've only noticed it happen on one channel (1080p hevc m3u stream) and appears to happen when it records several episodes in a row, with the first episode seemingly appending the subsequent runtimes into its reported runtime. And every episode thereafter being incrementally shorter on reported runtime by approximately what should be the normal runtime.

Unfortunately when I first noticed this happening I had a knee jerk reaction and started deleting problem episodes, but I WANT to say the very last episode in that stretch reported normal runtime.

 

If it will help the devs I can submit a bug report with zipped copies of some of the problem recordings and my logs, as well as anything else that might help?

[Luke 38863]

19 hours ago, tmurphy2792 said:

Is this still a known issue being investigated?

I found this post while searching for solutions to the problem I'm having. It appears I'm experiencing basically the same thing as OP.

So far I've only noticed it happen on one channel (1080p hevc m3u stream) and appears to happen when it records several episodes in a row, with the first episode seemingly appending the subsequent runtimes into its reported runtime. And every episode thereafter being incrementally shorter on reported runtime by approximately what should be the normal runtime.

Unfortunately when I first noticed this happening I had a knee jerk reaction and started deleting problem episodes, but I WANT to say the very last episode in that stretch reported normal runtime.

 

If it will help the devs I can submit a bug report with zipped copies of some of the problem recordings and my logs, as well as anything else that might help?

Hi, what is the live TV source?

[tmurphy2792 18]

1 hour ago, Luke said:

Hi, what is the live TV source?

In the example given above it was this source.
https://d1mumb5jst6zw0.cloudfront.net/v1/master/3722c60a815c199d9c0ef36c5b73da68a62b09d1/cc-rqzc6u2smk8dg/ion.m3u8

But going back through my recordings it seems to have happened once or twice with different recordings from this source.
https://bcovlive-a.akamaihd.net/cde8d9416f6d4f1da0a4e8cfde6e8b2c/us-east-1/6240731308001/playlist.m3u8

 

Both of these links are in a local .m3u8 file on my Emby server and Emby is pointed to said file. I've gone ahead and attached that file in case it helps.

free tv_DIRECT.m3u8

[Luke 38863]

OK we'll take a look at it. Thanks.

[tadr 1]

Is there any additional information regarding the cause of, or resolution to, this issue?  I've been having this issue for a while now as well.  It also seems to happen when multiple shows are scheduled to record sequentially on the same channel.  For example, I record three back to back shows on the same channel every week.  Frequently, one or both of the later two shows will show durations of 17-20 hrs each, and are essentially unwatchable.  Let me know if there's any information I can provide that would be helpful.

[Luke 38863]

On 1/10/2025 at 11:17 PM, tadr said:

Is there any additional information regarding the cause of, or resolution to, this issue?  I've been having this issue for a while now as well.  It also seems to happen when multiple shows are scheduled to record sequentially on the same channel.  For example, I record three back to back shows on the same channel every week.  Frequently, one or both of the later two shows will show durations of 17-20 hrs each, and are essentially unwatchable.  Let me know if there's any information I can provide that would be helpful.

Hi @tadrcan you please provide a specific example?

How to Report a Problem

Thanks !