Topic: Recording Critical Error pop up (Read 2964 times)

tzr916 · « **on:** June 04, 2018, 05:36:43 pm »

Was watching a recorded show on the Server, at 6pm screen went black then pop up on the screen regarding "Critical error inserting JRiver time shifting..." with an "OK" button. So I clicked Ok on my remote, the show I was watching resumed and I noticed one of my HDHR Prime tuners light up.

Investigating TV Logs today shows the error(s). Looks like recording for "Dateline" did not fire, but recording for "Disappeared" did fire. AND the Tv Guide did not load this morning either. See first screenshot.

I tried loading the Guide from MC and it failed at the mc2xml screen with a line saying "missing -g". I tried a Clear Guide data from MC, then re-ran loading Guide and it failed again with the same "missing -g". I rebooted the PC, re-ran loading Guide, same "missing -g". I manually navigated to the C drive mc2xml folder and tried double-clicking the exe, same "missing -g". Finally, I deleted the .dat and .xml files, then loaded Guide from MC and it worked this time. See second screenshot.

Hope my guide loads tomorrow, we shall see. Suspect those critical errors at 6pm caused more issues than just a few recordings not firing. Wondering what else would have (not) happened if I wasn't at the server, able to click the "ok" button!

Yaobing · « **Reply #1 on:** June 04, 2018, 05:52:00 pm »

Usually Critical Errors occur when there is a hardware issue. I will investigate.

MC2XML's "-g" parameter is postal/zip code. It is strange why it would be missing.

The Critical Error Information Message box has a 10 seconds timeout, after which it would self-destruct. So if you were not there to see it, it would not be such a disaster.

tzr916 · « **Reply #2 on:** June 05, 2018, 12:13:22 pm »

Also, just noticed that episode of "Disappeared" started recording at 6PM but didn't stop recording until around 2AM, resulting in a 20hour long show with size of 33GB. Have no idea what happened at 2AM to stop it, I was sound asleep.

Yaobing · « **Reply #3 on:** June 05, 2018, 12:59:39 pm »

Quote from: tzr916 on June 05, 2018, 12:13:22 pm

Also, just noticed that episode of "Disappeared" started recording at 6PM but didn't stop recording until around 2AM, resulting in a 20hour long show with size of 33GB. Have no idea what happened at 2AM to stop it, I was sound asleep.

That usually happens when the main thread of MC is blocked for some reason. In this particular case MC seems to be unblocked after 20 hours. A new build of MC will partially address this issue. It will not be perfect, but hopefully it will stop the recording earlier, resulting in smaller recordings and less wasted disk space.

Mans · « **Reply #4 on:** June 06, 2018, 06:45:02 am »

Hi OP and Yaobing,

I did noticed the same thing twice recently.
Ending up with some hugh recordings.

I did checked the name of the file, it has the correct title of the program in it. So it isn't caused by an incorrect or incomplete EPG.
Due some reason the recordings just weren't stopped.
When i noticed the XXL file, i did tried to stop the recording manually but 'this recording is already finished' showed up.
Had to kill MC Server in order to stop the process.

Thanks Yaobing, once a new built is out i'll test and rapport back to this thread.
In case you want us to test something, don't hesitate to ask.

Yaobing · « **Reply #5 on:** June 06, 2018, 09:26:33 am »

Quote from: tzr916 on June 04, 2018, 05:36:43 pm

Looks like recording for "Dateline" did not fire, but recording for "Disappeared" did fire.

This is a weird one. I can not find evidence in the log file of "Dateline" on June 3. I did find a completed recording done on June 1, 10 pm - 11 pm. That recording ID somehow ended up not being cleared and was reported on June 3. So maybe you did not miss that particular show on June 3. If you take a look at the TV Logs image you posted, the Dateline show was reported to be on channel 804, the same channel on which "Disappeared" was to be started, and the time was 10 (pm), the time it was started on June 1. I still don't know why there was a critical error.

Can you tell from "TV Logs" whether the same tuner that recorded "Dateline" on June 1 was used for other shows on June 2 and 3 up until the critical error?

tzr916 · « **Reply #6 on:** June 06, 2018, 10:41:25 am »

Quote from: Yaobing on June 06, 2018, 09:26:33 am

...Can you tell from "TV Logs" whether the same tuner that recorded "Dateline" on June 1 was used for other shows on June 2 and 3 up until the critical error?

Some strange stuff going on with Dateline on 6/1:

6/5 7:23p ch369 "saksi" recording finished - tuner 868-1
6/5 6:45p ch369 "saksi" recording started - tuner 868-1
6/5 5am EPG load success
~Machine and tuners rebooted~
No record of ch804 "disappeared" recording stopped - tuner 868-1
6/4 2:39am EPG load failed
6/3 6p ch804 "disappeared" recording started - tuner 868-1
6/3 6p ch804 "disappeared" critical error - tuner 868-1
6/3 5:59p ch804 "dateline" critical error - tuner 868-1
6/3 5am EPG load success
6/2 11p ch713 "cbs news" recording finished - tuner 868-1
6/2 10p ch713 "cbs news" recording started - tuner 868-1
6/2 5am EPG load success
6/1 11p ch703 "dateline"recording finished - tuner 68e-1
6/1 10p ch703 "dateline" critical error - tuner 686-1
6/1 10p ch703 "dateline" recording started - tuner 68e-1
6/1 9:59p ch703 "dateline" critical error - tuner 686-1
6/1 5am EPG load success

Dateline has NEVER recorded on ch804, ever. No idea why it tried to record on 6/3. But just in case, I went ahead and modified Dateline series to only record on ch703, it was set for All + 703.

Noticed:
-Critical error always one minute before top of the hour, then again one minute later.
-Successful recording on tuner 686-1 @ 6/2 10-11p ch713 "cbs news".

Yaobing · « **Reply #7 on:** June 06, 2018, 12:37:55 pm »

Quote from: tzr916 on June 06, 2018, 10:41:25 am

No record of ch804 "disappeared" recording stopped - tuner 868-1
6/4 2:39am EPG load failed
6/3 6p ch804 "disappeared" recording started - tuner 868-1
6/3 6p ch804 "disappeared" critical error - tuner 868-1
6/3 5:59p ch804 "dateline" critical error - tuner 868-1

Quote

6/2 11p ch713 "cbs news" recording finished - tuner 868-1
6/2 10p ch713 "cbs news" recording started - tuner 868-1

Quote

6/1 10p ch703 "dateline" critical error - tuner 686-1
6/1 9:59p ch703 "dateline" critical error - tuner 686-1

Quote

-Successful recording on tuner 686-1 @ 6/2 10-11p ch713 "cbs news".

Are 686-1 and 868-1 two different tuners or just typo?

tzr916 · « **Reply #8 on:** June 06, 2018, 01:24:47 pm »

Hmm... I'll check that when I get back home.

Yaobing · « **Reply #9 on:** June 06, 2018, 03:17:39 pm »

Quote from: tzr916 on June 06, 2018, 01:24:47 pm

Hmm... I'll check that when I get back home.

You have tuners "...6B6-#", "...30A-#", and "...68E-#". No "868" or "686".

So, all the troubles were on one tuner, "... 6B6-1". Apparently the reference counting was off by one, that prevented the tuner from being completely unloaded after each recording.

tzr916 · « **Reply #10 on:** June 06, 2018, 04:44:36 pm »

Yes, all troubles were on 6B6-1, typos on my end. I put in the 68E-1 lines in on purpose for context. The B really looks like an 8 when viewing 4k Server via remote desktop on a 14" laptop screen

Quote from: Yaobing on June 06, 2018, 03:17:39 pm

...Apparently the reference counting was off by one, that prevented the tuner from being completely unloaded after each recording.

What causes "the reference counting off by one"? Is it going to continue to happen? Should I do anything on my end? Or it's something that might be done on your end?

Yaobing · « **Reply #11 on:** June 06, 2018, 04:55:12 pm »

I am still looking.

Yaobing · « **Reply #12 on:** June 07, 2018, 06:31:12 pm »

Quote from: tzr916 on June 06, 2018, 04:44:36 pm

What causes "the reference counting off by one"?

It was caused by missed communication between the server and a client. When a client stops playing a channel, it is supposed to tell the server that it is done. For some reason, that message was not received by the server and the server later discovered that a client was not communicating, it did a poor job of cleaning up. That was the cause of the wrong reference counting.

In an upcoming build we will have the following:

Changed: TV does a better job purging clients that have stopped interacting with the server.
Fixed: Wrong info was reported in "TV Logs" when there was a critical error on the TV engine.
Changed: TV does a better job of cleaning up when a critical error is encountered.

I am still working on the other issue: a recording was not stopped when it should be.

Yaobing · « **Reply #13 on:** June 08, 2018, 12:26:10 pm »

I could not find more clues on why the recording was not stopped. I saw repeated attempts to stop the recording, but each time it was not done. It was probably caused by the fact the internal state was messed up due to missed communication between the server and a client. Hopefully the better cleanup routines I added yesterday will cause this not to happen. We will see.

One thing I would like to suggest to all users: make sure you click Stop before you leave client playback. Do not just leave it in paused state for a long time. Do not close MC without stopping live TV playback first.

tzr916 · « **Reply #14 on:** June 08, 2018, 01:39:48 pm »

Thanks for the great work. Waiting for the next release.

I think I know what happened (prior to the critical error)- I'm guessing my girlfriend left live tv playing on an upstairs client without me knowing. I now remember seeing a show on the server that said "currently recording", and I selected "delete". I was thinking it was a left over time-shift, not a client actively playing live tv.

Just performed a test, and sure enough - deleting a "currently recording" show on the server (which is actually a client playing live tv) does NOT stop playback on the client. And if you then press stop on that client - the tuner does NOT release.

Not sure if your upcoming fix addresses this situation or not, but seems this kind of thing could be prevented if a "currently recording" show wasn't presented on the server when live tv is being watched on a client. I know this has be discussed before. Is there actually a reason it still needs to? I really wish there was a way to turn it off... Maybe you can put that in an upcoming release?

Yaobing · « **Reply #15 on:** June 08, 2018, 02:56:15 pm »

The server should not allow a currently recording show to be deleted. If it did, I will try fixing it. Also the file that is currently being served to a client needs not be displayed but I have not fixed that because of the logistics. It is one of those things that require special treatment and having too many special treatment codes is a nightmare for maintenance. In this particular case, however, it is probably worth doing.

RoderickGI · « **Reply #16 on:** June 08, 2018, 08:07:36 pm »

Sorry to butt in, but this may affect me!

Special Treatments are a bad thing. What if a TV show is actually playing on a Client, but doesn't show up under Television Recordings and so you (or a user who doesn't know about this special case) just kills MC or reboots the server? What if a TV process does indeed get stuck but isn't visible anywhere so a user doesn't know it needs to be cleaned up?

Besides, if you look at the Reporter tool instead of just the Television Recordings section, you will see that a TV Recording is running. I don't think that shows up if TV isn't actually showing at the time. You would have to check when you get a real case of a stuck TV session, perhaps an active TimeShift session left over after a TV viewing was stopped.

I would rather that a Client's live TV is shown under both the Reporter and the Television section, but perhaps rather than being identified as a recording, it should be identified as a "Live TV" session, or maybe as a "TimeShift" session if it is a Timeshifted Live TV session. I don't know if it is difficult to differentiate between a recording and a Live TV session, or a Timeshifted TV session, but if Client connections were correctly identified this problem wouldn't exist.

Thanks for considering.

tzr916 · « **Reply #17 on:** June 08, 2018, 08:56:01 pm »

I agree it would be very nice if these could show up in Standard View, or even better have the ability to create a Theater View page for showing a live over-view of all tuners and clients. Similar to how Custom [=TVInfo(Record)]=[1] is a "to be recorded" list.

Currently, allowing a client's live tv session to be displayed under "shows" in Theater View, as a recording in progress on the server and all clients, with the ability to choose watch and/or delete, is not elegant (and risky).

Yaobing · « **Reply #18 on:** June 09, 2018, 05:42:21 pm »

Thanks Roderick for chiming in. You are right about not hiding the files that are being served to clients.

I did some quick testing today. I found out that it is not possible to delete a file while a client is still using it. In standard view, "Delete" is disabled for such files (including files that are currently recording, or currently served to clients). In Theater view it is not so good, in that the Delete button is available for these files. You can click it, and get confirmation about deleting. The good news is that although MC pretends to delete the files, they are actually not deleted. I will need to hide "Delete" interface for them in Theater view.

If you were actually able to delete such a file, the client connection was already lost. Putting the video on pause for a long time on a client is one way to get the server to stop serving the client. As I said before, the server did not do a good job of cleaning up. It will in a new build.

RoderickGI · « **Reply #19 on:** June 09, 2018, 05:55:13 pm »

Would it be easy to label these connections something other than "Currently Recording", as per my suggestions above? That would probably go a long way to solving the issue, by making the actual status visible.

Maybe a TVInfo function could return different results, based on whether it is a recording, and live TV session, or a TimeShift session.

Having a tuner status function in Theatre View isn't a bad idea as well, although I tend to drop back to Standard VIew whenever do ing any sort of maintenance to checking of any status. Obviously, not everybody does, as not everybody has a wireless keyboard sitting next to their sofa!

Mans · « **Reply #20 on:** June 10, 2018, 05:58:22 am »

+1, I'm into the same boat.

Thanks Yaobing and OP for any work on additional or more detailed info inside Theater- and Standard View.
And I'm always happy to test or give input if wanted.

Sat>IP server with 4 tuners, 1x dedicated VM for MC Server -> 3x MC clients.
So a lot of TV live sessions, TV recordings etc thru the house.

Cheers.

INTERACT FORUM

Author Topic: Recording Critical Error pop up (Read 2964 times)