Is the Id *really* capable of handling 96k+ flac files in real time when rendering from DLNA? Or in all cases, even?
When I originate a DLNA stream from my server to Id it does a lot of what sound like buffer drops (a few seconds of audio) or sometimes short skips/drops. Every once in a while it will stutter, repeating a few seconds that it just played. This problem appears to be worse if Play from Memory is enabled. Almost like something is interrupting the audio in/out ring buffer pointers randomly. Most of the time I see it on FLAC files that are 176k or 192k, sometimes 96k, and seldom on 44k or 48k (but it does occasionally happen). It doesn't seem to happen in the same places on the songs, it's much more random than that.
I've changed the audio device output to DragonFly to a fixed 96k, but it makes little difference. Currently I'm trying it on HDMI audio with the DragonFly removed. So far nothing has changed.
Now, if I have the Id load my Server's library directly, and play from there, the same playlists, the symptoms lessen greatly, but still happen once in a while. Especially track re-starts after 20 or seconds of play. Also, premature jumps to a new song before the current song is done. And little burples in the audio, tiny skip here, tiny skip there... subtle but present.
My internal network is a switched GigE (1Gb), wired, and all devices are in the same /24 subnet. There is no packet loss at all. The same library server sending via DLNA to another MC on a regular computer works with no loss of any kind, and other machines attached to the server library or sharing files on the same filesystem (the same path designation on each computer) have no issues whatsoever. From the same server I can feed video or audio anywhere in the house with no issues at full bitrates (highest is BluRay at just shy of 50Mbit/sec).
So that takes it back to the Id as far as I can see.
Other lingering issues include:
System freezes (hardware lockup),
software freezes (hardware still responding) but only a reboot will start it working again.
If songs have stopped playing, the HDMI display still goes off even though the Disable Display from turning off option being checked. As long as tracks play the screen will stay on.
The first reboot after a crash will not run correctly most of the time. It's confused about the library it was on (asking for credentials for a library it has not connected to), or will start to play and then just disappear, or other nonsensical behavior. Next reboot it seems fine.
Opening Tools->Options->Audio->Audio Device->Device Settings while a song is playing will blow away MC completely, but it will restart by itself in about 20 seconds (watchdog restart?). Accessing Device Settings seems ok if nothing is playing.
I have not yet tried to duplicate any of this with a local library on the Id.
Could all these erratic behaviors have a common denominator? Such as a fault in this particular Intel NUC model motherboard? Either a design problem, or just not enough CPU to start with?
--Bill