Downgrade getMetaInfo warning to debug for expected non-JSON responses

[derekcentrico]

Problem

WiiM devices return "Failed" or an empty body (HTTP 200) from the getMetaInfo endpoint when nothing is playing. Both trigger json.JSONDecodeError in session_call_api_json, which logs a WARNING before raising LinkPlayInvalidDataException. On a 5-second poll cycle this produces hundreds of warning lines per day in Home Assistant logs:

WARNING [linkplay] Unexpected json for https://192.168.1.222/httpapi.asp?command=getMetaInfo: Expecting value: line 1 column 1 (char 0)

PR #93 added the data field to the exception and a catch in bridge.py for data == "Failed", but the warning was already emitted by that point. Empty-string responses were not handled at all and re-raised.

Reported in #128 and in Home Assistant core issue #175775.

Fix

Two changes:

1. utils.py: Before logging, check whether the raw response is empty or "Failed". Log at DEBUG for those cases, keep WARNING for truly unexpected payloads.

2. bridge.py: Broaden the catch to also treat empty-string responses as a non-error (same as "Failed"). Uses an isinstance check so exceptions raised without an explicit data string still re-raise correctly.

Tests

Adds test_meta_info_empty_response_handling alongside the existing test_meta_info_failed_handling. All 291 tests pass.

Closes #128

[firstofjuly]

Independent reproduction on a different device model, in case it helps with review.

Device: WiiM Mini (project: Muzo_Mini, hardware: ALLWINNER-R328, firmware Linkplay.4.6.819436)
Stack: Home Assistant 2026.7.0, python-linkplay 0.2.14

Confirmed the endpoint returns a bare 6-byte non-JSON body when idle (status: none):

$ curl -sk "https://<device>/httpapi.asp?command=getMetaInfo"
Failed

Scale on a single idle device: 537,992 warnings over ~8 weeks (Jul 4 – Aug 30), which was 74% of all log entries on that instance. It buried several genuine faults — a dead sensor battery and an offline camera each went unnoticed for weeks because the log was unreadable.

Worth emphasising that the device is entirely healthy: 15/15 requests answered in ~0.08 s across getPlayerStatusEx, getStatusEx, getMetaInfo and getNewAudioOutputHardwareMode, from two separate hosts. So this is purely the log-and-raise in session_call_api_json emitting a warning for a condition bridge.py already treats as expected.

The stripped in ("", "Failed") approach looks right to me. Handling the empty-body case as well as Failed matters — I only found the Failed variant when diagnosing this, and would have missed the empty case.

One note for anyone landing here from search: this cannot be resolved by updating Home Assistant. Both 2026.7.0 and 2026.8.3 pin python-linkplay==0.2.14, so until a release ships, the only mitigation is silencing the logger:

logger:
  logs:
    linkplay: error

[derekcentrico]

@Velleman Any chance you could take a look at this when you get a moment? We now have an independent reproduction from @firstofjuly on a different device model (WiiM Mini), logging over 500k warnings in 8 weeks from this single endpoint. The fix is minimal and scoped to the two known non-JSON responses ("" and "Failed").