Transporter Not Playing

[edwin2006]

Just curious, is it connected via wifi or ethernet? Can't this be just a network connect problem?

[bpa]

Just curious, is it connected via wifi or ethernet? Can't this be just a network connect problem?

No because in one of the two instances, the trace of slimproto communication shows the network connection is working but player is telling LMS do not send any more data and player is not decoding the data in its buffer presumably because firmware has detected something wrong in the DAC or output hardware

[rich.herbs]

Just curious, is it connected via wifi or ethernet? Can't this be just a network connect problem?

Ethernet. Although for completeness, I just connected the transporter via wireless, and the problem is present. So I don't think the network connection is a factor.

[Fizbin]

What does the voltage say? It's displayed in the Settings/Information tab.

[rich.herbs]

What does the voltage say? It's displayed in the Settings/Information tab.

See my first post from this morning.

[Fizbin]

Ah, found it. Ok.

[bpa]

Ethernet. Although for completeness, I just connected the transporter via wireless, and the problem is present. So I don't think the network connection is a factor.

Did you read Joe Muc blog
https://joes-tech-blog.blogspot.com/...er-repair.html
Especailly the section Noisy DAC / Bad Analog Output
Are the DAC LEDs working ?

[alfista]

Easy enough to check the DAC LEDs, but reading Joe's blog I doubt it's the issue here. Those voltages seems to be more relevant for the analogue side of things. A buffer not emptying seems more digital. The clocking solution on the Transporter seems to be a fair bit more complex than on other players of that generation. Isn't there a setting for clock source that can be set through LMS? Maybe try fiddling with that?

[bpa]

Easy enough to check the DAC LEDs, but reading Joe's blog I doubt it's the issue here.

Agreed but it's something that can be checked without any test gear.

It's interesting that similar symptoms and yet most of the Transporter seems to be functional.

[rich.herbs]

...It's interesting that similar symptoms and yet most of the Transporter seems to be functional.

Absolutely. It's as if someone performed very delicate brain surgery.

To check the voltage I modified the CLI to include the voltage and wrote a script to check the voltage regularly, which showed that the voltage drop occurred after a reboot. I was able to recreate it several times:

• Transporter is off, showing the screensaver. Voltage is 130V.
• Press and hold the power key on the front panel. The unit shuts off completely, clicks, an audible burp is heard through the speakers, and the unit restarts with the welcome screen.
• At this point, the voltage is listed as 49V.
• The voltage stays at 49V for a few minutes. Either the wait or asking it to play another track cause the voltage to go back up to 130V.

I have no idea if this is related to the "not playing" issue, but I thought I'd report it.

When the transporter is asked to play a track and doesn't get past the first second, the status reports mode:play waitingToPlay:1 time:0. The time:0 confirms that zero seconds have been played (i.e. player stalled), and the waitingToPlay:1 is, according to the CLI documentation "A flag telling whether the player isn't actually playing, but still waiting for data or something." All this confirms the symptoms, but doesn't help much.

Perhaps a more experienced person could get something out of the status log showing the steps I went through to cause the voltage drop. I did it 5 or 6 times, so the steps listed in transSubscribeLogCleanFinal.txt consistently cause my transporter's voltage to drop, and the entire status for the transporter's various states is included.