Print

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

[cFortC]

For some years I've been using the scheduler to record a concert program that runs past my bedtime, so I can listen the next day.
There seem to be phases of JRiver releases where this works fine, and other periods of time when the releases consistently start failing to complete the recording.
The Record Stream URL detects some error and stops recording mid-stream.
For a while (perhaps for some version of JRiver), I could work around this by continuing the audible playback of the same URL (turned off the power amp when I went to bed).
This workaround is not working for the current JRiver version.

Some history: I didn't see this problem for quite some time. The later in the year version JRiver 30 started showing it again. When JRiver 31 came out, the problem went away for most of the year, but in the past approximately one month the problem has returned.

The URL being recorded is: http :// streaming.azpm.org/kuat192.mp3
(I have seen the problem on another URL but this is the one that I listen to most of the time).

I have attached the log, as saved after the most recent occurrence (yesterday evening). I have deleted zillions of entries before and after the issue in order to reduce the size of the log to an attachable file.

I realize the URL stream itself would of course be suspect. This is a very high quality stream and during audible playback I can tell that it is smooth going for weeks at a time.

Please take a look. Are other JRiver users seeing any similar problems with Scheduled Record Stream?

[JimH]

It's possible you're being disconnected by the server.

[cFortC]

I realize that the server is the first suspect. As noted, this stream seems to be a very reliable, high quality source and any such disconnects are not evident during the times I am audibly playing the stream.

What I'm hoping is that the log analysis could turn up either a cause, or further troubleshooting steps to nail this down.

[cFortC]

Here is some additional information on my configuration that might be relevant.
JRiver is running on a "headless" PC (Dell micro-form factor) controlled from my laptop via Remote Desktop Control.
It is a known "feature" of RDC that normal music streams are terminated on the target machine if the RDC session is closed.
That is why I've always used the ASIO drivers and interface for the DAC -- ASIO continues to play in this situation.

Back to this issue: it seems that the Scheduled Record stream doesn't fail while I've got the RDC session active.
In all recent occurrences of the issue, the stream has failed SHORTLY AFTER I closed the RDC session as prerequisite to sleeping the laptop. This circumstantial connection between closing the RDC session and the failing of the Scheduled Record stream, while implausible, is certainly possible since we are dealing with the vagaries of Microsoft Windows here.

As a test, yesterday evening I kept the laptop on and the RDC active for four hours. The Scheduled Record stream stayed operational the entire time.

Does this failure syndrome ring a bell with anyone who may have struggled with Windows audio?

If there is actually a connection, then the workaround would be as simple as it is onerous - just keep the RDC session up and running.

[JimH]

Or use a different remote desktop solution.

[cFortC]

Actually, I have used TeamViewer in the past, attempting to work around RDC's blockage of normal audio playback when the session drops.
I just didn't like the intrusive character of the TeamViewer software and the feeling that they were monitoring my connections.
However, since then I have converted completely to ASIO audio interfaces, and also installed a more reliable Wi-Fi grid at my location.
Because it's built into Windows and otherwise works very well, I standardized on RDC.

Since my previous post, I have been using an old laptop to maintain an active RDC session after I've retired to bed. Since I determined that active playback of the recorded stream has no impact on the issue, I can shut off my DAC and power amp. This scheme has worked well, with no failures to complete a recording over at least two weeks.

If the JRiver developers have no further insight into the cause of the apparent RDC issue impacting Scheduler: Record Stream, then I am left with workarounds like the spare laptop or reverting to TeamViewer. Inconvenient, but doable.

[cFortC]

I tried the latest TeamViewer to ensure that it was still a valid workaround to this Record stream problem.

Well, not in my case. My main laptop has a 4K screen with very high DPI. When I run TeamViewer against the JRiver PC, no combination of the scaling and screen resolutions offered by TeamViewer yield a usable interface. The icons, text, etc. are either microscopic or you're looking at a desktop that needs to be scrolled within the TeamViewer window.

However, while I had TeamViewer installed, I did verify that a 2-hour Record stream session ran to completion.

[terrym@tassie]

Try NoMachine, I use it for my headless Windows/Linux servers and it works well, of course YMMV. Ditched Teamviewer because of their continuous accusations that I was 'using the software for commercial purposes' despite the fact that all my connections were on a local lan to 4 systems!

[cFortC]

Thanks for this suggestion about NoMachine.

I gave it a shot, but a few rough edges tend to squash it for my use. A blocker was NoMachines' use of the upper right hand corner to access its settings window. My JRiver has taken to opening a full screen options window whenever I select Playback Options. I opened this to check the audio devices under NoMachines. Then it was impossible to close the Playback Settings window - I could only reach the NoMachines settings window.

Other potential issues were NoMachines' preference to send audio through to the display client. I unchecked that box but I never reached the point where I could test ASIO audio on the server (see first issue). I'm also not impressed by that fake mouse sprite (which the real mouse sprite drags around on the screen) - TeamViewer has that same thing (with the kicker that the fake mouse sprite can easily become disconnected from the real one).

I've got to hand it to Microsoft Remote Desktop: it really is nicely integrated into the WIndows GUI experience. If it didn't break audio streaming (or JRiver Record Stream) on the host, it would be perfect.

[cFortC]

Well, yesterday the JRiver Record Stream failed, apparently when I momentarily minimized the Remote Desktop window on the laptop (in order to check a local setting on the laptop). The playback went on normally so I didn't notice the record stream failure until I checked the audio file later.

So I've updated my cautionary on Microsoft Remote Desktop Control: the session must not only remain active but also open on the desktop of the controlling PC. Otherwise, some sort of devilish glitch could halt non-ASIO audio playback or cause an ongoing JRiver record stream to stop recording.

At this point I started rethinking using Remote Desktop at all. How about a small keyboard and portable display attached to the music service micro-PC?

Looking into that, I concluded: maybe later. For the time being, I will just dedicate my old laptop (that one I was running RDC on) to BECOME the music server. It eliminates RDC and keyboard/display are built into the laptop.

[cFortC]

DIRECTION OF THIS ENQUIRY CHANGED

Even under optimal conditions (active open Remote Desktop Control window with playback active), I have still seen failures of Record Stream.
I finally noticed the failures all occurred around 75 minutes into a recording.

Since this whole line of enquiry around Remote Desktop Control has failed to fully resolve the issue, I revisited the premise of my original post of this topic.
There I noted that the problem began appearing during the release cycle of MC 30 updates (and continued into MC 31).

I decided to revert to MC 29 - the version prior to noticing the start of the problem.
(It's not feasible to revert to an early MC 30 release, and I know that the final MC 30 exhibits the problem.)

So I installed MC 29 on my music server micro-PC.
I ran three consecutive two-hour Record Stream scheduled activities, under "worst case" conditions.
Worst case entails no concurrent playback of the recorded stream and a closed (disconnected) Remote Desktop Control session.

All three Record Stream activities ran to completion with no data interruption or loss.

This result is not a proof since it could have been a fluke.
However, recent experience indicates that reverting the MC version is a very hopeful cure for the problem.

The result implies that some defect was introduced during the MC 31 release cycle that breaks Record Stream (URL).
It may be a clue that the recordings tend to fail about 75 minutes in.
Based on the testing just concluded, Remote Desktop is not related to this failure.

[cFortC]

Well, that "fix" described in my post just previous lasted longer than some of the other "fixes" that I've posted.
This time, it went a full week with no streaming or record stream problems.
Then the problem returned. As of yesterday, even under ideal conditions, the streaming URL that I am listening to can suddenly stop with "Buffering...". Oddly, it never recovers the playback by itself. The "buffering" is forever. A quick manual restart of the web media resumes playing immediately.

Whenever this occurs, any and all Record Stream operations in progress stop recording any new audio data.
They still show as "Running" but in fact they are just looping on some internal error.
To emphasize, a Record Stream for the same URL as the "Buffering..." playback, as well as any other Record Steam operations in progress for a different URL -- they all fail the same way.

This all points to my internet connection / ISP as a potential factor (different URLs both get hit at the same instant). Yet it is a gigabit fiber connection that has been 100% reliable. No other services or applications seem to be affected. Although originally I had a Wi-Fi link in the data path, I have since adjusted that so that a 100% wired path exists from the modem to the music PC.

In any case, since it is now demonstrated that MC 29 is not the answer to my internet radio streaming woes, I will un-revert back to MC 31.

Anyone else having stubborn "Buffering..." issues with URL playback and/or Record Stream failures?
Any other suggestions for workarounds to try?

[cFortC]

I managed to comprehensively analyze the JRiver MC log for a simple failure of the Record Stream.
50 minutes into the operation, the record loop encountered:
   CWINInetReader::Read: InternetReadFile returned true with zero bytes read: EOF
The loop then appeared to attempted the internet read one more time, and received the same result.
After that, JRiver went into the close-down sequence for the Record Stream.

Additional information: I was listening to the same URL stream (on a different PC) and there was absolutely no interruption, pause, blip, or any other indication of a problem with the stream or the internet.

Questions:
  (1) The read loop for Record Stream performs one retry before giving up.
        Is it possible to increase the retries to allow the process to continue over some momentary glitch?

  (2) Is a more robust recovery process possible? e.g. re-open the URL but continue appending to the same destination file?
        I'm even OK with a new destination file in this case.
 

[cFortC]

It's been five months since I've updated this string. The long delay was to allow the final resolution of the original issue to mature and prove itself. This is my analysis and proposed closure of the issue.

The original problem turned out to be three issues, and much confusion came from my attempt to nail down a single failure mode. Here are the three issues that I resolved:

(1) Mesh Wi-Fi network reliability. I'm using Cisco 240AC's and while these make an extremely robust mesh network with wireless backhaul, the reliability is not 100%. I ended up finding an acceptable route to connect, via CAT6 Ethernet cable, the switch in the music listening room directly to the switch co-located with the residential router. This eliminated the majority of random "buffering stalls".

(2) Duration of MC scheduled record URL tasks.  The great majority of record task spontaneous failures occurred at the 1-hour 15-minute point (+/- a couple minutes). I ended up standardizing all MC scheduled record URL tasks to 60 minutes duration. Adjacent record tasks (i.e. one task ends at 15:00:00 and the next task starts at 15:00:00) actually capture audio data overlapping by 15 seconds or so, so no audio is lost in this case. With this limitation on record URL task duration, it appears to me that spontaneous failure of record URL tasks is virtually eliminated.

(3) With solutions (1) and (2) applied, there is still a residual MC failure mode that affects active playback. If a record task is ongoing at the time, then the active playback failure also stops the record task. The symptom is the random onset of data buffering (playback halts of course) and MC never resumes playback by itself. I have no theory of cause, or solution for this failure mode, but MTBF seems at least one month, so I just chalk it up to the inherent reliability of software and networks.

Good luck to others who may have come across this issue. I hope this final posting is helpful.