LG TV app

[ssft]

I was talking the zipped NextPVR logs, they will show exactly where the calls are handled.  I understand the bug but that would be be on a skip in specific non-standard calls, I am trying to understand.

Martin

Ok I stopped the special reverse proxy that Claude built and ran a fresh session on the TV. Went to a channel and started it, nothing appeared on screen although UI still showed. Waited about a minute and then stopped the stream. Zipped logs are attached.

My session starts at this line in the log:
2026-07-29 17:52:10.150 [DEBUG][39] Got request [192.168.30.98]: /service (session.initiate)

[ssft]

Just wanted to provide more info on this. I had run out of my Claude session limits so I didn't really get a chance to have it nail down exactly all the changes it made to make it work. I had it write up a summary of what it believes the issue is and what it did to correct (by utilizing the reverse proxy it built). It wasn't just the duplicated Content-Range but rather 3 different things.

Attached the PDF of its summary. Hopefully this provides more insight.

[sub]

I'm not entirely sure it'll fix what you're describing here, but I've attached a newer version here you can try.

(I haven't looked at that PDF - I'm away on holiday at the moment, without my LG TVs, so not in a position to make any changes or test them right now)

[mvallevand]

Thanks for the logs and certainly try sub's ipk first since it might address the why streaming is not staring.

If now working with your Claude there are several things to give feedback on. First as I reported earlier it did identify an issue in code that is not used (except in Claude's faked test).

Second the Claude code report doesn't match what I see with curl tests. It doesn't not send either the Content-Length or the accept-bytes and it doesn't EOF after ~4s Perhaps this is another issue with how it is testing /live since the comments appear related to recordings not ?channel_id

Code:

curl "http://localhost:8866/live?channel_id=7909" -v -o test.ts * Host localhost:8866 was resolved. * IPv6: ::1 * IPv4: 127.0.0.1 * Trying [::1]:8866... * Established connection to localhost (::1 port 8866) from ::1 port 13484 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 0* using HTTP/1.x > GET /live?channel_id=7909 HTTP/1.1 > Host: localhost:8866 > User-Agent: curl/8.21.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK < Content-Type: video/MP2T < Date: Thu, 30 Jul 2026 12:50:42 GMT < Server: Kestrel < Transfer-Encoding: chunked < { [1323 bytes data] 100 28.87M 0 28.87M 0 0 1.51M 0 00:19 218.2k^C

Martin

[ssft]

I tried the 1.2.8 ipk but unfortunately has the same behavior. Click on a channel and nothing displays on the screen.

Here is Claude's explanation on the curl test:

-------------------------------------------------------------------

Reconciling the developer's curl output with actual server behavior discrepancies

Let me check exactly how the client authenticates, so I can give him a precise reproduction.

Reconciled authentication flow discrepancies and clarified testing methodology differences

He's testing a different code path than the app uses. The tell is in his command line:

curl "http://localhost:8866/live?channel_id=7909" -v -o test.ts

No sid. Every request the webOS client makes carries one, and we measured on your server that the presence of a valid session changes the response framing completely.

You captured both, earlier in our debugging. With a broken sid (I'd typo'd a space into it):

status 200
content-type: video/MP2T
transfer-encoding: chunked

No Content-Length, no Accept-Ranges. Then the identical URL with a valid sid:

status 200
accept-ranges: bytes
content-length: 996340536
content-type: video/MP2T

Same endpoint, same channel, minutes apart. The only variable was the session.

His own guess is probably the mechanism

He writes: "the comments appear related to recordings not ?channel_id" — and that likely explains it. With an active session and timeshift buffer, /live appears to be served from the buffer file using the same file-serving code as recordings, which is what emits Content-Length, Accept-Ranges, and the malformed Content-Range. Without a session there's no buffer file, so it streams straight from the tuner as chunked, which is the correct live behavior and what his curl shows.

That would also explain the EOF: a file-serving routine ends at end-of-file, whereas a tuner stream doesn't end. And it explains why timeshift only works once a session exists.

Exact reproduction

From index.html, the auth flow is:

GET /service?method=session.initiate&format=json&device=lg&ver=1.0
    -> returns sid and salt

hash = md5(":" + md5(pin) + ":" + salt)          // pin is "0000"
GET /service?method=session.login&sid=<sid>&md5=<hash>

GET /service?method=channel.stream.start&format=json&channel_id=7909&sid=<sid>

curl -v -o test.ts "http://localhost:8866/live?channel_id=7909&sid=<sid>"

The channel.stream.start step matters — that's what creates the timeshift session. Easier still: tune a channel in any client, grab the sid from its logs, then curl with it.

[mvallevand]

Claude is right the channel.stream.start method has a different path which I am testing now. It is important to use the sid from the channel.stream.start so you can't just use curl with any sid.

It look like the LG app is missing the &range=0- parameter for starting livetv

Martin

[sub]

ssft, I've made a change around this for the next build.

FYI though, neither of my LG TVs had any issue with the existing logic, but my TVs are older models than yours. It's possible WebOS 26 introduced some behavioural change though, which required this change.

After making the change, and no longer returning the Content-Range in this scenario, the live streams are still play on my TVs, so we'll get you to give it a go when the next release is out. Hopefully it'll help.

[ssft]

Yep it did work fine without any of the workarounds on my CX which is WebOS 5 I believe, so it's definitely a WebOS 26 thing.

[sub]

Yep it did work fine without any of the workarounds on my CX which is WebOS 5 I believe, so it's definitely a WebOS 26 thing.

Thanks - good confirmation info.