[BUG] Container information missing after commercial skip processing since version 1.21.2.3943

Server Version#: 1.22.0.4163
Player Version#: 8.14.1.23548
Tuner Make/Model: HDHomeRun compatible
Guide/Lineup name: Magenta TV Sat (Germany)
Using XMLTV?: no
Channel number/Name: All SD channels

Hi guys,

I’m new to Plex and love the commercial skip feature. Unfortunately, I’m facing a weird issue.

tldr: Updating part information after commercial skip processing removes container information since version 1.21.2.3943. Please read all posts to understand what’s going on exactly. Thanks.

I noticed the issue under following conditions:

  • Only on SD channels. No problem with HD channels.
  • Only with Direct Play / original quality. No problem when transcoding.
  • Only on Android TV (Fire TV Stick) an Android Mobile. No problem on Web Player, Plex for Windows, Plex Media Player.
  • On different Server platforms (tested on Synology, Docker, Windows)
  • Only if commcial skip is enabled in recording settings. No problem if commercial skip (ad detection) is enabled in library only even though the file is processed successfully.
  • Only in letterbox mode.
  • As long as commercial skip processing hasn’t finished yet, the recording can be played with no issue. On I find the the related entry in the logs (“Plex Commercial Skipper’ exit code for process 25101 is 0 (Commercials found)”) and start the playback again I have the issue.

It’s quite strange because as I understand comskip does not modify the media file and just add the the markers to the xml file. So maybe it’s more a player related issue!?

Sure, I could just disable comskip in recording and let the ad detection in the library do the work. But there are two reasons why that’s no option for me:

  • I’m not sure, but ad detection in library seems to be a scheduled tasks and doesn’t run directly after recording ends.
  • I have to disable commcerial skip in every recording manually, because if I disable it dvr wide it’s not available in the library settings (please understand this as feature request).

As you may imagine it was quite difficult to narrow down the issue to the findings above. Anyway, does anyone notice the behavior or maybe have a clue what’s oging on here? Any help would be appreciated. I will add logs oder media xml files if needed.

Thanks in advance.
Daniel

1 Like

Hi,

While waiting for a reply I did some additional research. Maybe the issue is related to rewriting tags after AdDetection of recordings through DVR. Please find full Media Info xml files attached for reference. For convenience reasons I did my tests on Windows, but that shouldn’t matter because, as I wrote before, the issue occurs on both Windows and Synology.

01_1082.xml.txt - Part section after recording was aborted and before AdDetection has been finished. I could play the file with no problem as long as AdDetection hasn’t finished yet.

<Part accessible="1" exists="1" id="1296" key="/library/parts/1296/1616332021/file.ts" duration="3114767" file="D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts" size="1418748392" container="mpegts" packetLength="188" videoProfile="main">

02_1082.log - Log excerpt of AdDetection after recording.

Mar 21, 2021 14:07:01.361 [25272] DEBUG - [Grabber/4ff9d5c33dad36da6ec637dc5f787b04432b5de0/AdDetector/JobRunner] Job running: set "FFMPEG_EXTERNAL_LIBS=\\\\?\\C\:\\Users\\Daniel\\AppData\\Local\\Plex\ Media\ Server\\Codecs\\367b3d4-3673-windows-x86\\" & "C:\Program Files (x86)\Plex\Plex Media Server\Plex Commercial Skipper.exe" "--ini=C:\Program Files (x86)\Plex\Plex Media Server\Resources\comskip.ini" "--output=D:\Temp\Plex\Filme\Jack and Jill (2011)" -t --quiet "D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts"
Mar 21, 2021 14:07:01.392 [25272] DEBUG - [Grabber/4ff9d5c33dad36da6ec637dc5f787b04432b5de0/AdDetector/JobRunner] Jobs: Starting child process with pid 11320
Mar 21, 2021 14:09:49.012 [25272] DEBUG - [Grabber/4ff9d5c33dad36da6ec637dc5f787b04432b5de0/AdDetector] EDL built after 167.7 seconds.
Mar 21, 2021 14:09:49.014 [25272] DEBUG - [Grabber/4ff9d5c33dad36da6ec637dc5f787b04432b5de0/AdDetector] Updating part with ID=1296 [D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts]
Mar 21, 2021 14:09:49.019 [25272] DEBUG - [Grabber/4ff9d5c33dad36da6ec637dc5f787b04432b5de0/AdDetector] Doing expensive tags write for 'Jack and Jill' because something changed.
Mar 21, 2021 14:09:49.022 [25272] DEBUG - [Grabber/4ff9d5c33dad36da6ec637dc5f787b04432b5de0/AdDetector] Updating part with ID=1296 [D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts]
Mar 21, 2021 14:09:49.022 [25272] DEBUG - [Grabber/4ff9d5c33dad36da6ec637dc5f787b04432b5de0/AdDetector] AdDetector: Removing all intermediate files at path `D:\Temp\Plex\Filme\Jack and Jill (2011)`

03_1082.xml.txt - Part section after AdDetection. When playing the file it is squeezed to 4:3 aspect ratio.

<Part accessible="1" exists="1" id="1296" key="/library/parts/1296/1616332021/file.ts" file="D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts" size="1418748392">

04_1083.xml.txt - Part section after Plex Dance. Playing is no problem.

<Part accessible="1" exists="1" id="1297" key="/library/parts/1297/1616332021/file.ts" duration="3114767" file="D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts" size="1418748392" container="mpegts" packetLength="188" videoProfile="main">

05_1083.log - Log excerpt of AdDetection within library by scheduled task.

Mar 21, 2021 14:56:33.630 [16356] DEBUG - [AdDetector/JobRunner] Job running: set "FFMPEG_EXTERNAL_LIBS=\\\\?\\C\:\\Users\\Daniel\\AppData\\Local\\Plex\ Media\ Server\\Codecs\\367b3d4-3673-windows-x86\\" & "C:\Program Files (x86)\Plex\Plex Media Server\Plex Commercial
Skipper.exe" "--ini=C:\Program Files (x86)\Plex\Plex Media Server\Resources\comskip.ini" "--output=D:\Temp\Plex\Filme\Jack and Jill (2011)" -t --quiet "D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts"
Mar 21, 2021 14:56:33.638 [16356] DEBUG - [AdDetector/JobRunner] Jobs: Starting child process with pid 11560
Mar 21, 2021 14:59:32.705 [16356] DEBUG - [AdDetector] EDL built after 179.1 seconds.
Mar 21, 2021 14:59:32.708 [16356] DEBUG - [AdDetector] Updating part with ID=1297 [D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts]
Mar 21, 2021 14:59:32.732 [16356] DEBUG - [AdDetector] Doing expensive tags write for 'Jack und Jill' because something changed.
Mar 21, 2021 14:59:32.735 [16356] DEBUG - [AdDetector] Updating part with ID=1297 [D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts]
Mar 21, 2021 14:59:32.735 [16356] DEBUG - [AdDetector] AdDetector: Removing all intermediate files at path `D:\Temp\Plex\Filme\Jack and Jill (2011)`

06_1083.xml.txt - Part section after AdDetection has finished. Playing still no problem.

<Part accessible="1" exists="1" id="1297" key="/library/parts/1297/1616332021/file.ts" duration="3114767" file="D:\Temp\Plex\Filme\Jack and Jill (2011)\Jack and Jill (2011).ts" size="1418748392" container="mpegts" deepAnalysisVersion="4" packetLength="188" requiredBandwidths="4604,4344,3834,3434,3434,3434,3434,3434" videoProfile="main">

As you can see the part section with id 1026 has been modified after AdDetection und the container and duration tags are missing. After a Plex Dance and subsequent AdDetetion processing the container as well as the duration tag are present and there’s als no issue anymore. So I guess there’s a bug rewriting the tags directly after recording provided that one or both tags are indeed related to this issue, but that’s the only obvious thing I could find.

So Plex, it’s your turn ;). I would really appreciate your help. Maybe someone else can confirm this behavior to push investigation by Plex.

Thanks, Daniel

01_1082.xml.txt (4.7 KB) 02_1082.log (1.6 KB) 03_1082.xml.txt (4.9 KB) 04_1083.xml.txt (18.3 KB) 05_1083.log (1.2 KB) 06_1083.xml.txt (18.8 KB)

I found the DVR setting the convert the recordings which I first thought that could be a workaround. But as the description says the feature ist still experimental. That could be the reason why it does not support hardware accelaration. Unfurtnately it also applies to recordings only an not to live tv which I would need because I have an issues with interlacing. To workaround that issue I use xteve with ffmpeg enabled (hw accelerated and deinterlaced). Before someone’s asking: I can rule out that ffmpeg is related to the 4:3 issue, because it also occurs when using xteve as buffer. It would be cool if the DVR could convert not only recordings but also live-tv, leverage hw accelaration and has an option to deinterlace. Maybe a Plex employee is reading this, but it’s is off-topic, anyway.

Back to the issue: With converting recordings the container tag is still missing in part section of xml file after comskip porcessing and updating the xml data, but that is no problem because the conversion adjusts the scale from 720x576 to 1024x576. Thus, there’s no problem viewing the recording. But the conversion is no option for me becaus it’s not hw accelerated yet. Therefore the focus is still on the missing container tag after comskip processing. Perhaps a Plex employee could have a look? It doesn’t has to be solved immediately, I would just be happy if anyone says this indeed a problem when the xml data is updated after comskip processing and takes it into account.

Just to complement, this is what it looks like after comskip processing:

I noticed that not only a Plex Dance brings back the container tag but also just an analysis:

grafik

Unfortunately, this still doesn’t help me a lot. I would prefer the commercial skipper would edit the extra_data in part table of the database correctly.

Extra_data cell content of part table immediately after comskip (container tag missing/incorrect):
ma%3Acontainer=&pv%3AcomskipIniFileSha=bd671226408ba1eb1ef63cc06ed863e7f9d378a1

Extra_data cell content of part table immediately after media analysis (container tag present):
ma%3Acontainer=mpegts&ma%3AdeepAnalysisVersion=4&ma%3ApacketLength=188&ma%3ArequiredBandwidths=3839%2C3839%2C3839%2C3839%2C3839%2C3839%2C3839%2C3839&ma%3AvideoProfile=main&pv%3Achapters=%7B%22Chapters%22%3A%7B%7D%7D&pv%3AcomskipIniFileSha=bd671226408ba1eb1ef63cc06ed863e7f9d378a1&pv%3AdeepAnalysisDate=1616695144&pv%3Aintros=

As you can see the container entry of the first content has no value. Thus, the player doesn’t know how to handle this recording and just displays the 720x576 as 4:3, even though the ts container holds the information that the recording is 16:9. In the player on my FireTV stick it says something like “Transcode reason: Container (null) not supported”.

I’m quite disappointed. Don’t get me wrong, but I did a deep issue analysis and it seems nobody cares. Anyway, I’m still hoping someone sees my postings and can check/resolve that or has a handy workaround in mind. Even though a reader cannot help, I would appreciate if one can point someone who’s qualified to this. I’m avaible for further investigation or tests, just let me know.

1 Like

Had this same issue recording on SD channel last night playing in Squashed 4:3 with direct play.

Only updated to the latest server version yesterday, so will try going back to previous version and see if it’s a temporary fix.

The opening poster has done a lot of leg work investigating, would be nice to see a plex employee at least acknowledge the issue.

I’ve just downgraded my Windows Plex instance to version 1.20.1.3252 because this is, as far as I know, one of the first version that introduces commercial skip. Without testing in deep, the commcerial marks are added to the xml immediately after recording successfully without touching the container tag. So, the error seems to appear in one of the later versions first.

Today, I’ve tested several versions to narrow down the first failing version. And what should I say, I was able to pin point the exact version, for which the problem the problem occured first. The version 1.21.1.3876 is the lastest version, where the commercial skip works as expected regarding the container tag in the part section. In version 1.21.2.3939 it seems that it doesn’t process the airing immediately after recording. It seems that this version has a problem with the feature. But in version 1.21.2.3943, which has been released one day after 1.21.2.3939, it processes the recording and the error occurs. If one checks the release notes, in version 1.21.2.3939 there have been made changes to the scanner (Analyze button, check here). I added [BUG] to the title to reflect the findings made within this thread. It would be great if another user could confirm this in order to push plex fixing this.

Thanks, Daniel.

C’mon Plex, please take this into account for one of the next versions and let us know you will. Shouldn’t be a big thing to fix this.

Commercial skip detection does not alter the original file and commercial removal only clips out the detected sections so if the file is changing aspect ratio’s it is something you are doing on your end.

It sounds like whatever you are using to emulate the HDHomerun is the issue which is not supported by Plex.

First, thank you for contributing. I’m aware that HDHomeRun compatible DVRs aren’t supported but should I have omitted this information or just lied? I don’t know whether you read the entire thread, but in later posts I said that the media information isn’t written correctly after comskip processing and therefore the problem isn’t related to the DVR model used. Ok, I have to admit that the title may suggest something different. But do you have a better sounding title? If so, please let me know, I will adjust that.

My postings describe the issue in detail. Sure, in Plex forum are so many posts, in which a user only states this or that is just not working without doing any troubleshooting in advance, but in this case I guess it’s worth a look by a Plex engineer.

Very similar to:

I made @anon18523487 aware of this in the other forum post on a similar and possibly related issue.

I saw it, thanks. I’m already watching your thread, too. Maybe the issue will be solved soon.

Yep. Certainly post if any fix addresses your issue too. They look like an identical issue to me. Your logs should certainly help. Looks like @anon18523487 just missed it.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.