maybe I should just put the server back on TrueNAS box.
I just really liked the idea of windows giving me hardware transcoding and comskip time reduced
from 20 minutes on NAS to just under 8 minutes on the Windows box.
I looked through the server logs on my 4 Channels DVR servers and the only times comskip exited with status 103 was when I deleted the recording while comskip was running.
Here is the last one
2023/05/24 21:12:47.542438 [DVR] Running commercial detection on file 6418 (TV/I Survived Bear Grylls/I Survived Bear Grylls S01E01 2023-05-18 Fangirl Gone Wild 2023-05-24-2005.mpg)
2023/05/24 21:20:05.055641 [DVR] Deleted #6418 /shares/dvr/TV/I Survived Bear Grylls/I Survived Bear Grylls S01E01 2023-05-18 Fangirl Gone Wild 2023-05-24-2005.mpg (user)
2023/05/24 21:31:30.790297 [DVR] Commercial detection failed for I Survived Bear Grylls S01E01 2023-05-18 Fangirl Gone Wild 2023-05-24-2005.mpg with exit status 103
Maybe permission issue or something interfering with comskip trying to read the recorded file, or write to the log directory.
This doesn't look right. Why was the show deleted 8 minutes after commercial detection started. Then commercial detection failed 19 minutes after detection began.
I trashed it and emptied the trash.
comskip failed because it could no longer read the deleted recording file or write to the comskip log directory.
well if it is it's got me stumped because I can write to it.
################################################################
Generated using donator Comskip 0.82.011
Time at start of run:
Fri Jun 09 12:01:00 2023
################################################################
this is a test
another odd thing is they will not play in web GUI with hardware or software transcoding but will play in Andriod client on my phone with no issue.
either of you running a Windows server?
If so what actions do you see on a reboot?
I get a Chrome window opening to the GUI and am running as a background service which I did not get on previous install and no icon in sys tray which I find odd as it's running as a service.
Could a mapped network drive be causing this as I was getting DB fails using the UNC because for what ever reason windows was having to search for the SMB share after every reboot and the server could not find it fast enough. once mapped it broke my virtual channel so moved to the UNC path which fixed virtual and no more DB errors but did leave it as a mapped network drive so it was available quick enough on reboots.
Can't help there, mine are on Synology NAS's.
Any errors in the DVR log when you try?
I don't run it on Windows, but the install notes mention running netplwiz.exe
Do you have Channels DVR writing to a UNC path?
Yes and I tried that and hosed the system and had to roll back to a restore point from 6/1 because I had no admin access to my system (would only show a no option whenever admin rights required)
here is the log first recording is one of the fails the second is from before they showed up.
2023/06/09 17:38:21.885025 [ENC] Starting encoder for 9-1-1 S02E05 2018-10-15 Awful People 2023-06-09-1500.mpg in \\TRUENAS\DVR-storage\Streaming\file1274-ip127.0.0.1-771542527\encoder-0-812089714 at 0 (0.000000) (encoder=remux, resolution=, deinterlacer=blend, bitrate=3882, segment_size=0.01)
2023/06/09 17:38:21.929932 [HLS] ffmpeg: file1274-ip127.0.0.1: [mpegts @ 00000000013dbe80] Packet corrupt (stream = 2, dts = 3113015392), dropping it.
2023/06/09 17:38:21.929932 [HLS] ffmpeg: file1274-ip127.0.0.1: [mpegts @ 00000000013dbe80] Packet corrupt (stream = 1, dts = 3113015392), dropping it.
2023/06/09 17:38:44.990589 [ENC] Stopped encoder for 9-1-1 S02E05 2018-10-15 Awful People 2023-06-09-1500.mpg in \\TRUENAS\DVR-storage\Streaming\file1274-ip127.0.0.1-771542527\encoder-0-812089714 after encoding 0 to 219
2023/06/09 17:40:25.005385 [ENC] Starting encoder for NCIS Los Angeles S03E08 2011-11-08 Greed 2023-06-07-0600.mpg in \\TRUENAS\DVR-storage\Streaming\file1270-ip127.0.0.1-1818750116\encoder-0-658351708 at 0 (0.000000) (encoder=remux, resolution=, deinterlacer=blend, bitrate=3897, segment_size=0.01)
2023/06/09 17:40:25.045370 [HLS] ffmpeg: file1270-ip127.0.0.1: [mpegts @ 000000000132bf80] Packet corrupt (stream = 2, dts = 1824876826), dropping it.
2023/06/09 17:40:25.045886 [HLS] ffmpeg: file1270-ip127.0.0.1: [mpegts @ 000000000132bf80] Packet corrupt (stream = 1, dts = 1824876826), dropping it.
2023/06/09 17:41:09.984216 [ENC] Stopped encoder for NCIS Los Angeles S03E08 2011-11-08 Greed 2023-06-07-0600.mpg in \\TRUENAS\DVR-storage\Streaming\file1270-ip127.0.0.1-1818750116\encoder-0-658351708 after encoding 0 to 394
Sorry I don't know how you get those nice neat boxes.
Yes that is how it is getting to the SMB share on the TrueNAS box.
Perhaps I use UNC incorrectly it's a network share
```
Paste text between lines of 3 backticks
```
I think that may be the problem, user account for the SMB share vs what account Channels DVR runs as. On my Synology NAS's I setup some usernames/passwords that are identical to the user accounts on my Windows laptop so I can access my Synology NAS's from the Windows laptop using SMB. They are also all under the same WORKGROUP NAME.

Paste text between lines of 3 backticks
thanks for that, makes it much easier to read.

I think that may be the problem, user account for the SMB share vs what account Channels DVR runs as. On my Synology NAS's I setup some usernames/passwords that are identical to the user accounts on my Windows laptop so I can access my Synology NAS's from the Windows laptop using SMB. They are also all under the same WORKGROUP NAME.
Well I have mine set to allow guest and all my boxes run on the same workgroup name.
However after doing my restore I better double check this Windows box. All good still the same.
Maybe someone doing what you are, or a developer can help since I don't run Channels DVR on Windows.

Maybe someone doing what you are, or a developer can help since I don't run Channels DVR on Windows.
Well I do thank you for the help a lot of times it's just throwing out ideas or talking throught it that gets it solved.
TBH I'm surprised one of the Devs has not dropped in and beat me about the head and shoulders for mucking up their weekend
See if this thread helps
run services.msc and look for channels DVR example below browse for user, [image] [image]

See if this thread helps
that seems to have done the trick!
2023/06/09 22:09:17.981895 [ENC] Starting encoder for 9-1-1 S01E01 2018-01-03 Pilot 2023-06-09-1100.mpg in \\TRUENAS\DVR-storage\Streaming\file1272-ip127.0.0.1-1364264037\encoder-738-703218507 at 738 (737.737000) (encoder=remux, resolution=720, deinterlacer=blend, bitrate=5488, segment_size=0.01)
2023/06/09 22:09:18.036785 [HLS] ffmpeg: file1272-ip127.0.0.1: [mpegts @ 000000000132b5c0] Packet corrupt (stream = 2, dts = 1817044680), dropping it.
2023/06/09 22:09:18.036785 [HLS] ffmpeg: file1272-ip127.0.0.1: [mpegts @ 000000000132b5c0] Packet corrupt (stream = 1, dts = 1817044680), dropping it.
2023/06/09 22:09:18.038321 [HLS] ffmpeg: file1272-ip127.0.0.1: [mpegts @ 000000000132b5c0] Packet corrupt (stream = 2, dts = 1817044680), dropping it.
2023/06/09 22:09:18.038321 [HLS] ffmpeg: file1272-ip127.0.0.1: [mpegts @ 000000000132b5c0] Packet corrupt (stream = 1, dts = 1817044680), dropping it.
2023/06/09 22:09:18.043491 [HLS] ffmpeg: file1272-ip127.0.0.1: [mpegts @ 000000000132b5c0] Packet corrupt (stream = 2, dts = 1817044680), dropping it.
2023/06/09 22:09:18.043491 [HLS] ffmpeg: file1272-ip127.0.0.1: [mpegts @ 000000000132b5c0] Packet corrupt (stream = 1, dts = 1817044680), dropping it.
2023/06/09 22:09:23.590690 [ENC] Stopped encoder for 9-1-1 S01E01 2018-01-03 Pilot 2023-06-09-1100.mpg in \\TRUENAS\DVR-storage\Streaming\file1272-ip127.0.0.1-1364264037\encoder-738-703218507 after encoding 738 to 824
2023/06/09 22:09:33.149215 [DVR] Running commercial detection on file 1272 (TV\9-1-1\9-1-1 S01E01 2018-01-03 Pilot 2023-06-09-1100.mpg)
Still seems to show some kind of error in the logs but plays almost instantly in the GUI now.
And here are the results of detection.
2023/06/09 22:15:21.303790 [DVR] Commercial detection for 9-1-1 S01E01 2018-01-03 Pilot 2023-06-09-1100.mpg finished with 8 markers in 5m48.1571566s.
much better then the 20 minutes on the old hardware on the NAS.
Ok so I was now able to run comskip from the options for the 3 recordings I had earlier today that failed.
All ran with no issues, although the last recording is a bit strange in the results as in the math for time does not add up.
Summary
16 min show + 4 min ads = 1 hr 2 min
0.00s — 518.77s
518.77s show
(9 min in 2 blocks)
518.79s — 730.10s
211.31s commercial
(4 min in 6 blocks)
730.12s — 1140.83s
410.71s show
(7 min)
I don't know what's going on with that one
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.