Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[curiousMonkey]

I am using MC 28 and controlling playback with JRemote. This configuration has been stable for quite a long time. This evening I noticed that the information displayed by JRemote on my iPad was not always accurate. I would attempt to update the playlist and nothing would happen. I restarted the app a few times and it never had any problem connecting to MC but it was still not behaving correctly.

Eventually I managed to get audio playback started but there is a delay of about 2.5 minutes between each track that is played. I also see a similar delay if I try to switch tracks by selecting another track from the list.

During this time I was also recording a television program in the background. I thought that might somehow be related to the sluggish response although I have not seen this problem in the past. I waited until the program should have finished but did not see any improvement. However, as I finished typing this message, about seven minutes after the recording completed, I noticed that the track playback is now happening immediately (normal behavior).

[curiousMonkey]

The problem has reappeared, exactly one week after the first occurrence. Once again I am recording a program, so I will wait for the top of the hour and see what happens.

[curiousMonkey]

Once again, performance performance had returned to normal when I tried to play music after the recording completed.
Something strange is definitely happening.

[curiousMonkey]

The program fails to record when I notice this behavior. I reviewed the directory where programs are stored and it looks like MC tried over and over again to start recording. There is a new directory for each minute of the hour when the program is on the air but they are all empty. I see the same series of directories for each failure over the last three weeks.

However several other programs are recorded successfully later that night, after the system recovers and stops being sluggish.

[JimH]

Check read/write permissions.   Same for parent directory.

Check disk space.

Set the recording directory to another location/drive.

[curiousMonkey]

Other recordings work fine using that directory, so I doubt permissions or disk space is an issue. I deleted the subscription for that one show and then added it again. Hopefully I will get different results on Sunday.

[curiousMonkey]

I collected the Sunday night log file this week. It seems to me that the program is busy looking for recordings but not actually saving any program. I deleted all scheduled programming from 6PM-7PM on Sunday. Something is still triggering the recording checks. I see an endless stream of empty directories, just as I described earlier.

Can someone decode the log file and explain what actually happens during this hour?
What is the easiest way to clean up the list of programs that are being checked in the log file? I see a lot of old programs that have either been canceled or no longer interest me. I am not sure where this information is stored by MC.

[JimH]

Is the signal for that channel weak?

Did you configure Windows Defender?

[curiousMonkey]

The signal strength for the channel seems fine at the moment, the picture and sound are stable.
I tried using the HDHomerun app to get an actual signal strength but I could not find that information.

I am using Windows Defender and see that MC is listed as an app that has firewall access.
The menu choices I am seeing with Windows 11 don't match the screen shots provided in the Wiki for excluding particular directories from scans. I don't see any option for that. However I believe that I may have made changes on an earlier version of MC (and Windows) to skip scanning the directory where I am still storing TV recordings.

[Yaobing]

About 2 and a half minutes into the log, there was a recording start attempt, on DMS channel 13.1.  MC failed to connect to the given URL for that channel and timed-out after 20 seconds.  I have not read the rest of the log but I expect to see MC trying again and again for several times.

[curiousMonkey]

When I examine "To Be Recorded", there is nothing scheduled for 6-7PM on 13.1. I specifically deleted this recording a few weeks ago. Where else can information about a recording be stored? Apparently there is some resiliant information hanging around. It would also be nice to clean up the long list of scheduled programs that appear in the log.

[Yaobing]

Did you do a library restore after you deleted the scheduled recording?  That could have brought it back.  I am not sure why you did not see it in To Be Recorded though.  The scheduled recordings are stored in an xml file tvrecording.xml, in the Library folder.  It would not have come from anywhere else.  You can check "Recording Rules" in addition to "To Be Recorded".  "To Be Recorded" shows you near future recordings, whereas "Recording Rules" shows you all rules, including recently expired and canceled rules.

[curiousMonkey]

I went ahead and cleaned up the XML file. There were a lot of entries for 60 Minutes.
I have attached the original file here for reference, renamed .txt since .xml is not allowed.

[Yaobing]

Yeah, you had 7 rules for "60 Minutes".  One rule specifies "All Channels", another specifies channel 2325085, the rest of them specifies channel 683845 (these are database keys for TV channels.  You can see them in Manage Channels).

What bothers me is why it failed to make a connection to "http://<Ip>:5004/auto/v13.1" where <Ip> is the IP address of your HDHomeRun FLEX 4K.  Did the network go bad?  Or the tuner malfunctioned?

[curiousMonkey]

I am not aware of any issue with my tuners. I can generally watch all channels reliably. Now that all of the rules have been cleaned up, let’s see what happens when the show returns next year.

[curiousMonkey]

The problem has reappeared last night and again tonight on different channels.
I was able to record successfully earlier this week.
The last two recordings created 1000+ directories as they repeatedly failed to actually record a file.

I will attach another log file from today's result. I tried recording the last 10 minutes of a program and it once again generated a lot of empty directories.

[Yaobing]

This time the behavior is a bit different.  Last time the log showed that networking call timed-out after 20 seconds.  This time it failed quickly, in 2 seconds.

The channels involved, 13.1 last time, and 10.1 this time had different IP addresses.  I think IP address change might be the cause.  Have you been resetting your LAN?

The new log shows that channel 10.1 is using an URL of http://192.xxx.xxx.3:5004/auto/v10.1 (with the last part of IP address being 3).  Previously the last part of the IP was 13.

You can check if your FLEX 4K device's IP address currently matches the IP address of channel 10.1.  If they don't match, recording will fail.  This is an oversight on my part.  I had actually added code so that playing a channel live would dynamically correct IP address discrepancy.  I should have done the same for recording too.  I will do it tomorrow. 

In the mean time you can first confirm whether IP address of the device has changed.  Another way to test is to simply try watching the problem channel live, without trying to record.  If that is successful, check the channel details and see if MC automatically corrected the IP address.

[curiousMonkey]

There was unexpected power loss in that room on Thursday and the IP address of my HTPC did change. I did not think about the IP address of the HDHomerun changing as well since it is in a different room although it is on the same network.

I manually checked the IP address and it now ends in 6. I ran the tuner configuration process again in MC and tried recording a short sample. It seems to be working now because I see a file added to the Recent panel and the system is responding normally.

[curiousMonkey]

The problem must be related to channel 13.1 specifically. The problem reappeared at 6PM when I tried to record 60 Minutes. I had to wait until 7PM before I could restart MC. I collected the log and will attach it here.

After collecting the log I started recording the NFL game on NBC (3.1) and it seemed to record correctly. I then started a second stream back on 13.1 and the system stopped responding again. After stopping MC I see a single directory was created for 3.1 but 13.1 had the usual sequence of empty directories.

At 8PM I will restart MC and see how it does recording some shows on PBS (6.1).

When I restarted at 7:59PM, the NFL game resumed recording normally. Both channels 6.1 and 13.1 are generating multiple empty directories and the program is not responding to the mouse. I checked Task Manager and CPU utilization is less than 10% so I am not sure why MC is ignoring the keyboard.

I will need to wait until all programs finishing trying to record tonight so that I can collect the final log output.

[Yaobing]

Channel 13.1 still has an IP address that ends with .13 which is not correct.  Rescanning somehow did not override it (maybe a new channel was created instead of changing existing one).  You can open Manage Channels and examine the list.

As I mentioned before, the way to correct the situation is to watch the channel live once.  When you do that, MC makes IP address correction.

[Yaobing]

I made this change today for the next build:

Changed: When starting to record a DMS TV channel, MC will check and update the channel IP address to match that of the current device IP address.  This will fix recording issues caused by tuner devices changing IP address.

With this change, you will no longer need to manually intervene when IP address of the device is changed.  It however may be a good idea to assign a fixed IP address to the HDHomeRun devices so problems like this will not happen again.