Print

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

[Bert490]

I often find odd TV recording behavior if I use my PC during the show.  I often see that a show is "currently recording" hours after it is over.  If I don't notice it, the hard disk fills up and subsequent recording fails.  If I notice it, I have to kill MC to get it to stop recording.  The show then often appears as 2 files, one short and the other hours long.  I think when I log on to the Windows account (re-log on), it seems to stop recording to the current file and begins recording to a second file, and the second file does not stop recording at the end of the show.  If I don't log into the account during recording, it works fine.  Sometimes I see the same show recording on both tuners (Hauppage card) that don't stop, and a subsequent show then fails.

I have been using JRiver for years, and I don't think this happened before version 20.  Is there a setting I'm missing?

[Yaobing]

There have been other reports of similar behavior, but I have not received any actionable clues.  I hope you could help me establish a set of procedures to reproduce it.

I think when I log on to the Windows account (re-log on), it seems to stop recording to the current file and begins recording to a second file, and the second file does not stop recording at the end of the show.  If I don't log into the account during recording, it works fine.

I will try this out.

[muzicman0]

I also have this issue (and reported before), and I never log out of Windows...I am always logged in.  It happens so rarely though, that it is hard to figure out how to reproduce.  I haven't actually had it happen for 2 weeks or so...

[mwillems]

I also have the issue, and it's unrelated to logging in or out for me too (my server never logs out).  It's also very sporadic and hard to "catch" for me.  

It does only seem to happen to me when I'm interacting with JRiver.   That is to say I've never had a recording keep going when it both started and ended while I wasn't interacting with JRiver at all.  It always seems to happen when I'm interacting with the library during the recording.

One thing I've noticed which may or may not be related:  auto-import acts funny during TV recording with my HD Homerun Prime.  I noticed this while re-reripping a bunch of CDs recently.  Specifically, I've noticed two potentially related things:

1) If I manually run an import while TV recording is ongoing -and- the TV recording directory is included in the auto-import it will hang JRiver everytime (white screen/non-responsive).  JRiver will only un-hang when the recording finishes, although this can sometimes trigger the indefinite recording issue.  The hang is 100% reproducible for me.  

2) If auto-import in the background is on, it appears to be suppressed during TV recording whether or not the TV recording directory is included in import rules.  For example, when I put music files in directories watched by the server, they usually appear in the library within 5 minutes. If I put them in a watched directory while TV is recording, they do not appear until recording stops (or I run a manual import, although that leads to the issue in 1) if the TV directory is watched).  Adding files to auto-import watched directories during a recording also seems to produce the indefinite recording behavior sometimes (but not usually).

I've never seen an indefinite recording case on my system that wasn't tied to one of these two things (either manually running import, or adding files to watched directories with auto-import running in the background), but those things don't produce it everytime.  So it seems like library import may be mixed up in this, although I'd be interested if anyone else has any counter-vailing evidence.

[kstuart]

I've noticed two potentially related things:

1) If I manually run an import while TV recording is ongoing -and- the TV recording directory is included in the auto-import it will hang JRiver everytime (white screen/non-responsive).  JRiver will only un-hang when the recording finishes, although this can sometimes trigger the indefinite recording issue.  The hang is 100% reproducible for me.  

2) If auto-import in the background is on, it appears to be suppressed during TV recording whether or not the TV recording directory is included in import rules.  For example, when I put music files in directories watched by the server, they usually appear in the library within 5 minutes. If I put them in a watched directory while TV is recording, they do not appear until recording stops (or I run a manual import, although that can lead to the issue in 1).  Adding files to auto-import watched directories during a recording also seems to produce the indefinite recording behavior sometimes (but not usually).

It seems to me that 2) is correct behavior - MC20 should never mess with the disk while either a program is recording or a file is being played.

Thus what is missing is a popup when you try to manually run import while TV is recording, it should say:

" Import should not be run during TV recording "

[mwillems]

It seems to me that 2) is correct behavior - MC20 should never mess with the disk while either a program is recording or a file is being played.

Thus what is missing is a popup when you try to manually run import while TV is recording, it should say:

" Import should not be run during TV recording "

My audio folders aren't on the same disk as my TV recording directory, and after discovering issue 1) I removed my TV directory from the auto-import list.

Why on earth would I want auto-import not to work without explanation because a computer is recording TV to a different disk?

or a file is being played.

I also don't know why auto-import should not work during playback.  I always listen to music while adding files to the library (I expect that's fairly common).  Disabling auto-import during playback would make auto-import completely useless to me, because playback is perpetual at my house.  Which is why I'm thankful that auto-import currently works normally during playback.

If you're concerned about disk access, individual users have the option of turning off auto-import in the background.  That makes much more sense than silently nerfing auto-import;  I'm pretty sure the suppression here is a bug (meaning an unintended consequence), not a feature.

[muzicman0]

I must have jinxed it...just checked, and my SSD has been hammered since 8AM this morning...that is now 12 hours.  I wasn't home, so no interaction with the server has happened, as my wife would have no idea how to even access it since it is headless in an unused bedroom.

[Yaobing]

Is logging on? If so, please make sure you grab it.

[muzicman0]

unfortunately, no...I can turn it on, but it will most likely be 2-3 weeks before it happens again...is this ok?

[Yaobing]

unfortunately, no...I can turn it on, but it will most likely be 2-3 weeks before it happens again...is this ok?

I will take anything that you can provide.  The log will be huge, but it will be better than having nothing.

[Yaobing]

Did you all experience hanging of MC while run-away recording happened?  Did it involve multiple recordings (especially one recording was stopping while the other recording was still going on)?

[muzicman0]

In my case yesterday morning, the wife was just watching TV on a client...when she pressed stop on the client, the server just kept recording.  No hangs that I am aware of, but I didn't even notice it until 12 hours later.

[JimH]

Is it possible that she pressed pause and not stop?

[muzicman0]

possible...yes...probable...no.  I will check with her though to verify.

[muzicman0]

Well, it's a good thing I asked, as this wasn't actually a live TV session, this was a one off recording.  My wife was actually at work when this whole thing happened, (the recording was scheduled from 8:15 - 9:45AM).  Sorry for the miscommunication, but it appears that the issue was that the recording never stopped...although the .ts file is the right length, so it was just the .jtv file that kept going.  The reason I thought it was a live TV session is because the .jtv file said something about client playback in the file name (don't remember the exact file name/wording)...

is it possible that for some reason sometimes one off recordings are being started as a live TV session to a client, which explains why they wouldn't stop...

[Yaobing]

When you record in .ts format, there are two different .jtv files that might appear in the folder:

"... - Saved time-shifting.jtv" is a file created just in case the user wants to save the session on exit.  It goes away when time-shifting stops.  If time-shifting does not stop, it will be there.

"... - Client Playback.jtv" is used for serving a client.  This file does not appear in the folder unless a client is using TV.

[muzicman0]

yeah, it was the client playback file.

But, like I said, no one was even here, so there is no way that anyone initiated a session.

[Yaobing]

Maybe the "Client Playback.jtv" file was create long before the starting of recording on the channel?  Maybe on the previous night?

A few things you can check to rule this in or out:

date the file was created;
date the folder was create;
the name of the folder (does it match the name of the recording?)

[Yaobing]

but it appears that the issue was that the recording never stopped...although the .ts file is the right length, so it was just the .jtv file that kept going. 

So this appears to be a different issue from that of OP.  The time-shifting files are always limited to a certain number of hours (default is 4), unless a super long recording is going on.  If the .ts file is of the right length, recording did seem to stop properly, and it is not likely to fill up the disk.

[muzicman0]

Talked to the wife again...this is more confusing.

I think it is possible, but maybe not likely, that while she was watching netflix that morning, the remote might have been bumped, which could have started playback.  It would have had to have been bumped again, with the back button maybe or similar...my remote is RF, so it is certainly plausible.  (just FYI, I thought she worked that morning, but I was wrong, so she was home, but insists that she didn't watch any live TV, only netflix via the TV app).

What I am going to do, is add a cntrl-s (stop command) to the remote any time the back button is pressed...just to be sure that isn't what is causing the problems.  I can't think of a reason that I would use the back button where I would want playback to continue.

[Bert490]

It just happened to me again.  I will send a log file to Yaobing.  To clarify my symptoms, it does appear to be when interacting with the JRiver server application.  Typically, when I "re-log in" to my account I actually just re-enter the Windows password to stop the screen saver or change the user back to my Admin account; I am always logged in from a Windows sense (I don't think JRiver continues to work if I actually log out).  I often check JRiver first thing, so it's possibly the interaction rather than re-entering my Windows account.  At any rate, this particular time I was already using Windows before the recording started and there was very little interaction with JRiver; during recording I checked the Television Recordings list and I looked at a couple of episode titles under Video, Shows.  No playback.  It is now 20 minutes past the time the show ended, and there is one file of duration 16 minutes and a second file that is still 'currently recording'.  There was only one show being recorded.

[Bert490]

Attached is a screenshot.  The second entry for the show will eventually cause the HD to fill up.

[Bert490]

Here is the log file.  The show started recording about 1.25 hours before the last entry.  Around 1 hour before the log end, the time stamps are weird; some really low time-stamp entries appear, then they resume where they left off.  This seems to be the time the file is written to disk, then resumes recording to another file.

It was alot of work to clip this to the size accepted for posting, and personal messaged don't allow attachments.

[Yaobing]

the time stamps are weird; some really low time-stamp entries appear, then they resume where they left off. 

The out-of-order odd looking time stamps are from different processes (such as the JRWorker.exe doing importing/thumbnailing in the background). 

[Yaobing]

Thanks for the log. 

A recording was supposed to start at 10 pm (9:59 pm).  You edited too much of the log file, so it does not show whether and when it actually started on time.  If it started around 10 pm, why did it stopped.

Assuming it started recording but stopped for some reason, MC tried to start again at around 10:15 pm.  This one is a bit strange because MC tried to use a tuner that was previously initialized for EPG scanning (apparently there is some cleanup issue).

Other than the issues related to using a tuner that was initialized for EPG scanning, I do not see why the tuner would not stop recording.

How many tuners do you have?  Did you schedule over-the-air EPG scanning to start sometime before 10 pm?  Did the scan finish?

I need to see more of the log.  If you zip it and the size is less than 10 MB, it might work as an email attachment.  Otherwise, you may try using a file uploading service (such as Dropbox, or OneDrive).  Or, if you try editing it to a smaller size, try leaving it in its entirety between 9 pm (time stamp around 253150000) and 11 pm (assuming the recording is one hour).  My email is yaobing at jriver dot com

[Bert490]

Logfile sent via email. 

I use a single Hauppage PCI tuner card WinTV HVR 2250 with dual tuners.  I regularly record 2 shows at the same time.  EPG scanning loads automatically every 24 hours, and I don't remember what time I originally set it to (it would not have been prime time).  The current JRiver version now has an option of 'default' which is the current time setting.  I had not seen this screen before, and it shows 4 EPG loading modes, all selected (screenshot attached).  I had tried various EPG modes before, when only one was allowed at a time, and settled on the first one (AUTO from local cable provider).  I understand that even though more than one mode is now possible, one of these modes will override all the others (http://yabb.jriver.com/interact/index.php?topic=96125.0), and based on my detailed EPG data, it must be first one that is actually used.  I will try disabling OTA EPG to see if it affects the  odd recording behavior.

[Yaobing]

"Default" means "Do it the selected number of hours (which is 24 in your case) after last run, or as soon as possible thereafter".  The last item on your screenshot appears to be a bug, which I will look into.

The email has not arrived yet.

[Bert490]

The last item would have been an EPG source that I tried before but dropped; there was likely no provider named.  I would not spend time on it.  I disabled the last 2 but kept OTA and the local cable provider enabled.  The two EPG sources are necessary to get data for my channels.

[CountryBumkin]

That last item on the screen shot "Auto__Country, Postal Code, Provider" with no information (blank) is also shown on my system. So it may be a bug. However, it doesn't seem to be a problem on my system. Everything is working for me.

[Yaobing]

Logfile sent via email. 

It still has not arrived.  Probably rejected by email server for attachment that is too large.

[Bert490]

I'll try posting here again, trimmed and zipped.

[Bert490]

My log seems to show EPG loading happening for a while before the recording is re-started at timestamp 257664729 (when the second recording file is started, the one that never stops).  JWorker starts after that, creating the 0-based timestamps, so that can't be related to re-starting the recording.  It's not obvious why the end time is not honored in this state.

Since EPG loading via OTA requires using a tuner, I don't want it to interfere with recording in any way, so i reset the EPG starting time to 05 hours instead of default, and un-checked 'run selected profiles now'.  I suppose it's possible that the EPG load process does not defer gracefully when a recording is on (use alternate tuner or wait).  Setting an explicit starting time is a workaround that I hope works.  So far (one day later) no recording problems.

[glynor]

It was alot of work to clip this to the size accepted for posting, and personal messaged don't allow attachments.

Sorry for the trouble. In the future, to avoid this issue, don't post them that way.  Attach the ZIP file created by the logging tool.  Text files, including the log files, zip very efficiently.  That's why they put it in the zip file, and it includes other useful troubleshooting information, and both sessions (to make sure we don't get the wrong log).

If the zip file generated by the log is still too big to attach to a post (if it contains a crash dump or is many days long), you can:
(1) use WikiSend or a similar service (Dropbox, Google Drive, etc) to post a link to the file
(2) if you want the log to be private for some reason, you can send it in an email
(3) if it is too big to attach to an email, you can use Wikisend, Dropbox, etc to make a link to it and include that in your email.

Covered here:
http://wiki.jriver.com/index.php/Logging

[Yaobing]

I'll try posting here again, trimmed and zipped.

Thanks for taking the time to trim the log.

This file reveals more info. 

You had several recordings ranging from an 8 pm show to a 10 pm show.  Both tuners were involved in recording these show.  One of the tuners was in an incorrect state, due to previous EPG scanning that was not cleaned up properly, which left the tuner in EPG mode.  One consequence is that the tuner did not correctly filter out irrelevant streams when recording a show (streams of all sub-channels of a TV station are all dumped to the .TS recording file).  So you will notice that the .TS files are of larger than usual sizes.

At about 10:15 pm you probably entered Television view, which triggered a "Stop EPG" event.  MC incorrectly stopped a recording.  Then MC restarted the recording.  Thus you got two files for the same show.  The second one with a file name "xxxxxx (1).ts".

The log file ended at time-stamp 258628488 (or around 10:31 pm), at which time the recording is still going on.  I do not know if the show is supposed to stop at that time.  So I can not tell whether the recording continued on longer than it should have.

If you still have the log file, do you mind giving me the bottom portion of it (starting with time-stamp 258628488)?

I will look into the EPG problem and make sure we do a better clean up job.

[Bert490]

Sorry for the delay in responding.  There was an 8:00 show ending at 9:00 and a 9:00 show ending at 10:00 pm.  I stopped the log at 10:31 to show clearly that the recording went too long.  Once in this state, the recording stops only when I manually close Media Server and confirm that recording is to be terminated.  If I don't do this, the disk eventually fills.

Incidentally, now that EPG background loading is every 24 hours at 05:00 instead of 'auto', there have been no problems.  It seems the EPG scanning interferes with recording.  Settings that start recording 1 minute before and stop 1 minute after likely result in an attempt to use the second tuner even though the TV shows don't actually overlap.  The second tuner being occupied with EPG scanning may then result in this effect.  It would explain why we see this irregularly.  If the computer is off, then the EPG scan time (if 'auto' is selected) is likely set by the time JRiver next starts, and continues every 24 hours thereafter.  If I understand it correctly, a restart outside of prime TV time would almost never show this effect.

[Yaobing]

Sorry for the delay in responding.  There was an 8:00 show ending at 9:00 and a 9:00 show ending at 10:00 pm.  I stopped the log at 10:31 to show clearly that the recording went too long.  Once in this state, the recording stops only when I manually close Media Server and confirm that recording is to be terminated.  If I don't do this, the disk eventually fills.

Incidentally, now that EPG background loading is every 24 hours at 05:00 instead of 'auto', there have been no problems.  It seems the EPG scanning interferes with recording.  Settings that start recording 1 minute before and stop 1 minute after likely result in an attempt to use the second tuner even though the TV shows don't actually overlap.  The second tuner being occupied with EPG scanning may then result in this effect.  It would explain why we see this irregularly.  If the computer is off, then the EPG scan time (if 'auto' is selected) is likely set by the time JRiver next starts, and continues every 24 hours thereafter.  If I understand it correctly, a restart outside of prime TV time would almost never show this effect.

In your case, the EPG scanner that was not completely released was not causing the recording not to stop, even though it caused other unexpected behavior.  The EPG scanning appeared to have already stopped before the 8 pm show started.

If I remember correctly, the 8 pm show was recorded with that tuner, and the 9 pm show was with another tuner.  The 8 pm show was stopped correctly.  The 10 pm show was using the EPG tuner again. 

Yes, at 10:31 pm, the log shows that the show is supposed to be still going on.  It is hard to believe that the recording database got it wrong about it.  We check your recording rule and decide whether the recording should go on, and the check returned "true", thus the recording went on.

[Bert490]

My reading of the logfile timelines is slightly different (I hope my interpretation is correct).  Backtracking from the last time-stamp 258628488 being 10:31 pm, I see at 253190590 (~9:00) 2 shows are recording due to a small overlap, one of which stops (Arrow).  From 9:00 to 10:00 Nova records but before 10:00 (256672) EPG is running.  CSI starts at 10:00 (256675), and at 257651 it stops and restarts, and at 257653 EPG runs again (2 seconds later).  After that, the CSI recording does not stop.  The initial log file I posted on April 22 has an ending time stamp of 261262269 for 11:15 pm.  I unfortunately clipped the log entry confirming that recording had not stopped by 11:00, but you'll have to trust me on that one; the recording would have filled the disk.  It seems the stopping and restarting of the recording is related to that second EPG scan, and subsequent checks of the recording rule result in a "true" even after the show's end time.

[Yaobing]

My reading of the logfile timelines is slightly different (I hope my interpretation is correct).  Backtracking from the last time-stamp 258628488 being 10:31 pm, I see at 253190590 (~9:00) 2 shows are recording due to a small overlap, one of which stops (Arrow).  From 9:00 to 10:00 Nova records but before 10:00 (256672) EPG is running.  CSI starts at 10:00 (256675), and at 257651 it stops and restarts, and at 257653 EPG runs again (2 seconds later).  After that, the CSI recording does not stop.  The initial log file I posted on April 22 has an ending time stamp of 261262269 for 11:15 pm.  I unfortunately clipped the log entry confirming that recording had not stopped by 11:00, but you'll have to trust me on that one; the recording would have filled the disk.  It seems the stopping and restarting of the recording is related to that second EPG scan, and subsequent checks of the recording rule result in a "true" even after the show's end time.

What you see in the log file, and thought to be EPG scanning, were not EPG scanning.  They were caused by remnant of EPG object hijacking part of functionality of the tuner.  EPG scanning had already finished.  The logging lines that have reference to EPG are not showing EPG scanning in progress.  They would not cause the recording to not to stop, unless they caused some sort of hanging, which they did not.  Stopping recording is the function of another piece of the software, which did not stop recording at about 10:31 because it did not see the need to stop (recording rule still says "keep going").

In any case, build 103 should have fixed the OTA EPG scanner releasing problem.  You should install the latest version and keep an eye on recording functionality and see if the problem still occurs.