Duplicate recordings - Same Day, Different Channel

I recently noticed that Channels DVR had recorded the same Young Sheldon episode twice. As it turns out, said recordings occurred within three hours of each other on the same day but on different streaming channels. Today, I took a look at the upcoming schedule and noticed that more duplicate recordings are incoming.

These are only two examples but there are more.

Logs have been submitted as 4ef37ef6-5e41-46dc-b26b-fe7de9935489 . Show recording settings listed below.

EDIT: Adding screenshot that shows duplicate recordings.

The "Queued" notation only means that a particular episode is set to record, not that it will necessarily record. Once the episode records from the earlier East Coast feed, the DVR will mark it as recorded. When that happens, you'll notice that the upcoming episodes from the Pacific feed will have their status changed from "Queued" to "Recorded".

1 Like

To eliminate any confusion, I've added another screenshot that shows duplicate recordings that were generated for the same episode.

Was either show selected for recording by manually selecting to record the episode instead of relying upon the pass that was created? What do the DVR logs show for the two instances of the same episode being recorded?

To the first point: If you choose to manually select a program to record, it will record, regardless of rules/passes set or if it has already been recorded.

To the second: Details are always helpful, because otherwise everything else is simply a guess.

(Also, on your other thread, you have mentioned that you are moving and manipulating files via scripts outside of Channels. You also have this pass set to re-record deleted episodes. If you are moving a file and Channels thinks it has been deleted, it is possible that it is re-recording it because you set the rule to do so.)

1 Like

Side note - I had a much more elaborate response written but for some reason I posted the response in the wrong thread. So due to the forum's spam filter, this is a condensed version of my response.

Answer to Question #1

No manual recordings have been set to my knowledge. I assume these recordings were scheduled by the Show Pass created through Channels.

Answer to Question #2

Unfortunately, the logs don't go back far enough (only ~36 hours in the UI) to provide an answer to this question. This also means that the logs I previously submitted to support may not be helpful unless they somehow include historical logs dating back to Jan 19.

I'll keep an eye out for a recurrence of this behavior and will capture logs if/when it happens again.

In response to the point about my other thread

I'm glad you picked up on this because I briefly wondered how "Re-record Episodes if Deleted" would function within my use case. However, I've been removing commercials from recorded content and then importing the modified files to the Library in the same fashion for months with no issues.

In fact, my workflow does not include deleting any content until the modified content has been fully verified for functionality and accuracy within Channels. When I do finally delete anything, it is being done via the Channels DVR Web UI, not programmatically via script or manually via the Host OS.

The log that is shown in the web UI is truncated, but that does not mean you cannot access older entries. There are two options:

  1. You can directly access the channels-dvr.log file on your server
  2. When you navigate to the Support > Logs tab in the web UI, append ?n=10000 to the URL to access the last 10,000 lines of the log. (Of course, you can substitute whichever number you like.)

You other thread contradicts this, as you specifically mention about the same recording appearing twice after it was moved: the first initial import, as well as the second after you moved it after the initial import. Based upon this, my idea is that either you haven't noticed these edge cases, or that something has changed on your side but that you haven't picked up on or thought was relevant.

In either case, when you do things to library items or content outside of Channels, it makes troubleshooting or offering any support difficult, because you are introducing additional variables that none of us can really see.

I caught it happening about 3 weeks ago and submitted logs.
https://community.getchannels.com/t/channels-dvr-recorded-the-same-episode-twice/30718

If you manually recorded it the job# in the log will end with -channel# instead of -pass_rule#
https://getchannels.com/docs/getting-started/faqs/subscription/#how-can-i-view-more-of-the-channels-dvr-server-log

I can see how the two threads seem similar but they are in fact not related at all.

This thread is regarding two distinct recordings of the same show's episode being created on the same day at different times. The other thread is regarding the after effects of post processing against one specific recording.

This is good to know, thank you. I'll try digging through the logs to see if I can confirm the presence of a manual recording.

Managed to locate the logs. To my untrained eye, nothing stands out as abnormal to me.

Interesting aside - I had to use n=60000 to dig up these logs. :smiley:

FIrst Recording

2022/01/19 14:29:00.009124 [DVR] Starting job 1642631340-45 Young Sheldon on ch=[6033]
2022/01/19 14:29:16.124045 [TNR] Opened connection to TVE-YouTubeTV for ch6033 TBS
2022/01/19 14:29:16.185361 [DVR] Recording for job 1642631340-45 from TVE-YouTubeTV ch6033 into "TV/Young Sheldon/Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1429.mpg" for 31m59.990654304s
2022/01/19 14:29:16.849946 [IDX] Generating video index for job 1642631340-45
2022/01/19 15:01:00.092235 [TNR] Closed connection to TVE-YouTubeTV for ch6033 TBS
2022/01/19 15:01:00.332649 [MTS] Statistics for "TV/Young Sheldon/Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1429.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=0 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=1916.962467
2022/01/19 15:01:00.374605 [DVR] Finished job 1642631340-45 Young Sheldon
2022/01/19 15:01:00.579019 [DVR] Waiting 1h27m59.420989667s until next job 1642638540-45-EP026422390002 Young Sheldon
2022/01/19 15:01:01.271909 [DVR] Processing file-9167: TV/Young Sheldon/Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1429.mpg
2022/01/19 15:01:01.998793 [DVR] Running commercial detection on file 9167 (TV/Young Sheldon/Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1429.mpg)
2022/01/19 15:03:18.060640 [NAT] Successfully mapped port 8089 using natpmp
2022/01/19 15:06:29.893161 [DVR] Commercial detection for Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1429.mpg finished with 8 markers in 5m27.894727422s.

Second Recording

2022/01/19 17:29:00.008981 [DVR] Starting job 1642642140-ch6034 Young Sheldon on ch=[6034]
2022/01/19 17:29:00.010284 [DVR] Waiting 1h29m59.989722824s until next job 1642647540-45 Young Sheldon
2022/01/19 17:29:01.205895 [TVE] stream timestamps: tbsp: start_at=2022-01-19T17:18:53-08:00 current_at=2022-01-19T17:28:32-08:00 end_at=2022-01-19T17:28:44-08:00
2022/01/19 17:29:01.206635 [TNR] Opened connection to TVE-YouTubeTV for ch6034 TBSP
2022/01/19 17:29:01.206921 [DVR] Recording for job 1642642140-ch6034 from TVE-YouTubeTV ch6034 into "TV/Young Sheldon/Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1729.mpg" for 31m59.990836969s
2022/01/19 17:29:01.676170 [IDX] Generating video index for job 1642642140-ch6034
2022/01/19 18:01:00.124704 [TNR] Closed connection to TVE-YouTubeTV for ch6034 TBSP
2022/01/19 18:01:00.190449 [MTS] Statistics for "TV/Young Sheldon/Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1729.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=0 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=1934.982600
2022/01/19 18:01:00.277281 [DVR] Finished job 1642642140-ch6034 Young Sheldon
2022/01/19 18:01:00.460425 [DVR] Waiting 57m59.539583715s until next job 1642647540-45 Young Sheldon
2022/01/19 18:01:01.260397 [DVR] Processing file-9169: TV/Young Sheldon/Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1729.mpg
2022/01/19 18:01:01.883180 [DVR] Running commercial detection on file 9169 (TV/Young Sheldon/Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1729.mpg)
2022/01/19 18:03:18.068169 [NAT] Successfully mapped port 8089 using natpmp
2022/01/19 18:06:43.792261 [DVR] Commercial detection for Young Sheldon S02E08 2018-11-08 An 8Bit Princess and a Flat Tire Genius 2022-01-19-1729.mpg finished with 8 markers in 5m41.923898609s.

That's a manual recording, not from a pass. The -ch6034 is the giveaway.
job 1642642140-ch6034

That's from a pass, the -45 means pass rule#45
1642631340-45
You can see the json of that pass at /dvr/rules/45

Good catch. I knew I was missing something.

Is it possible to determine the source of the manual recording from the logs as well? So strange that this show would have any manual recordings configured as it is a relatively new addition to our collection...

Not that I know of.
Could have been selected from the grid guide, on later, the pass view when you click the # recordings scheduled, etc. Just means it wasn't 'scheduled' from a pass.

I just picked an episode from the grid guide and selected record.
The only thing I see in the log is this

2022/02/06 21:58:49.734573 [DVR] Waiting 2h31m10.265439499s until next job 1644222600-ch706 The Tenors: Best of Our Lives

In your case, you could search back in the log for the first entry containing 1642642140-ch6034 and the date/time will most likely be when that manual recording was selected.
How good is your memory?

If your sample is any indication, I doubt my log entry will be any more enlightening. At least we know the source of the extra recording. Thanks for the help.