LG TV app

[Allan]

FYI, you can set a HOST_IP environment variable for the server if you want it to explicitly use a specific address, rather than the detected address

Thanks sub. 

I added a HOST_IP environment variable to my launchdaemon (excerpt below) as explained by Martin, and the backend now responds with the correct IP address even if parallels or sonicwall is running.

Code:

… <dict> <key>PATH</key> <string>/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin</string> <key>HOST_IP</key>     <string>x.x.x.x</string> </dict> …

BTW, Martin, I never could get the launchdaemon to work using the NEXTPVR_DATADIR_USERDATA environment variable (as you can see above, I'm not using it). Instead, I use the UserName key, which has the effect of looking for and storing the .npvr-Data directory in my user's directory. I could not get a launchdaemon to work (only a launchagent) until I did that. Except for the little glitch we have discussed elsewhere, the backend has run rock solid with no user intervention.

[sub]

I added a HOST_IP environment variable to my launchdaemon (excerpt below) as explained by Martin, and the backend now responds with the correct IP address even if parallels or sonicwall is running.

Code:

… <dict> <key>PATH</key> <string>/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin</string> <key>HOST_IP</key>     <string>x.x.x.x</string> </dict> …

Great!

[Allan]

Will you be submitting this app to show up in the Webos store? Installing it (and regularly reinstalling it) via the developer app is never smooth sailing, and now appears to be impossible (for me anyway). Boring detail below.

Because it is installed with the LG developer app on the TV, it uninstalls itself every 999 hours (the maximum setting). Reinstalls are always challenging, but possible.

This time, I seem to have hit a brick wall. When I tried to log into the developer app on the TV, I received a spurious message that I am locked out because of 5 bad login attempts. When I tried to fix this online, the dysfunctional lgemembers.com login page claimed to have sent me an authentication code, but does not, in fact send me one. So, I am locked out

I have asked LG for help, but it would be nice to be able to do a regular install. I have the LG app, MrMC (abandoned Kodi branch for Apple TV) and your apple TV app avaiiable on our main TV. The LG app is the only one that will (mostly) work with an in progress recording.

[sub]

Will you be submitting this app to show up in the Webos store?

Maybe?

The process and amount of info I needed to submit made it sound pretty painful, which is why I haven't done it to date.

[Allan]

For what it's worth, if you have any time to spend on either the TVOS or LG app, I vote TVOS.

I feel that the TV manufacturer's own smart TV systems are dead ends. I have found the ones I owned (Samsung, LG) to be inferior to add-on boxes like appleTV or Roku, with inferior and soon abandoned apps from streaming services. The only apps I use natively on my LG TV are yours and live broadcast. Everything else is through the AppleTV.

[sub]

For what it's worth, if you have any time to spend on either the TVOS or LG app, I vote TVOS.

I feel that the TV manufacturer's own smart TV systems are dead ends. I have found the ones I owned (Samsung, LG) to be inferior to add-on boxes like appleTV or Roku, with inferior and soon abandoned apps from streaming services. The only apps I use natively on my LG TV are yours and live broadcast. Everything else is through the AppleTV.

Honestly, I hardly ever use my AppleTV these days, because I find the LG TVs "good enough", and it means I don't have to use the AppleTV remote

[ssft]

Hello,
I recently purchased an LG G6 OELD running WebOS 26 and found the NextPVR app provided here is not able to successfully play live streams. UI works but tuning into a channel just sits there with a black screen. I fired up a console session using the LG cli tools and starting digging into the issue.

Using Claude, it was able to determine the below issue with an http response coming from the NextPVR server (I'm running it on TrueNAS as a docker app). I had it build me a special reverse proxy which strips out the duplicate header words and now everything is working great.

Based on this console command I put in the inspector console while I was connected to the app and its output, it determined the issue below (Claude response in red)-

fetch("http://192.168.30.65:8866/live?channel_id=7159&sid=0660ce6906a14bb584d8c20e7c3c6a7d", {headers:{Range:"bytes=1000000-1001000"}}).then(r => { console.log("status", r.status); r.headers.forEach((v,k) => console.log(k + ": " + v)); return r.body.getReader().read(); }).then(x => console.log("got", x.value.length, "bytes"));
Promise {<pending>}
VM55:1 status 206
VM55:1 accept-ranges: bytes
VM55:1 content-length: 1001
VM55:1 content-range: Content-Range: bytes 1000000-1001000/124943880
VM55:1 content-type: video/MP2T
VM55:1 date: Wed, 29 Jul 2026 21:32:47 GMT
VM55:1 server: Kestrel
VM55:1 got 1001 bytes


-----------------------------------
Now look closely at this line:

content-range: Content-Range: bytes 1000000-1001000/124943880

The console prints key + ": " + value. So the key is content-range and the value is Content-Range: bytes 1000000-1001000/124943880. The header name is duplicated inside its own value. What's actually on the wire is:

Content-Range: Content-Range: bytes 1000000-1001000/124943880

RFC 7233 requires that value to begin with the units token bytes. Beginning with Content-Range: is malformed. Somewhere in NextPVR's Kestrel code someone wrote Headers.Add("Content-Range", "Content-Range: bytes ...").

That's the bug, and it explains every symptom:

• Plain GET returns content-length + accept-ranges → Chromium concludes seekable file
  
• To get duration from an MPEG-TS it must read the last PCR, so it range-requests the tail
  
• Server returns a correct 206, correct bytes, and an unparseable Content-Range
  
• Chromium can't verify the range was honored, so it won't trust the data or advance to HAVE_METADATA
  
• No error is raised, because nothing failed at the transport layer — it just waits
  

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

[mvallevand]

@ssft can we get the zipped logs? That looks like the issue is seeking live streams, not playing live streams.

Martin

[ssft]

This particular line "fetch("http://192.168.30.65:8866/live?channel_id=7159&sid=0660ce6906a14bb584d8c20e7c3c6a7d", {headers:{Range:"bytes=1000000-1001000"}}).then(r => { console.log("status", r.status); r.headers.forEach((v,k) => console.log(k + ": " + v)); return r.body.getReader().read(); }).then(x => console.log("got", x.value.length, "bytes"));" is a special test injection it gave me to put into the console so it could see how the server responded back, it isn't the actual snippet from when it was attempting to play.

The console contained the below snippet from when it was attempting to play the stream (before the proxy workaround). It didn't have the response headers so it gave me the one above to inject in the console so it could see them. Let me know if you want logs from the server itself still, I can undo the reverse proxy workaround and get you those if needed.

ui.load
index.html:416 /live?channel=11.2&sid=8ab6926e4d60472fa43760e2fc905d56
index.html:416 start new playback: /live?channel=11.2&sid=8ab6926e4d60472fa43760e2fc905d56
index.html:416 checking playback type *2
index.html:416 playback is for live tv
index.html:416 http://192.168.30.65:8866/service?method...e2fc905d56
index.html:416 player_ts: http://192.168.30.65:8866/live?channel_i...e2fc905d56
[/quote]

[mvallevand]

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