More > JRiver Media Center 31 for Windows

Scheduler: Record Stream URL fails mid-stream

<< < (3/3)

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.

Navigation

[0] Message Index

[*] Previous page