Ability to change the DVR IP

[Renkyz]

Hi, I've been using your fork of Threadfin ever since the original version introduced past v1.1.12 where the remote interface could not be accessed on any machine besides the localhost. I had been using your version 1.1.15 for a while and tried updating to 1.2.0 when you released it, but it changed my DVR IP from the machines local IP (in my case 192.168.0.116) to localhost 127.0.0.1. For some reason, this let me retrieve my m3u playlist in VLC media player, but none of the channels actually played anything. I checked my logs and saw that there were not even any requests to load a channel, so I went back to the version that was working.

I've just tried v1.2.3 and found the behaviour is still the same, so I found the settings.json file to see if there was a way to change the DVR IP but I only found a way to change the listening IP, which as far as I can tell just sets which IP's are allowed to access the web interface.

Is it at all possible for you to add in a way to configure the DVR IP?

[Renkyz]

Interestingly, I just noticed after re-launching my 1.1.15 version that in the log, it states the DVR IP. 2024/08/10 03:08:38 [Threadfin] DVR IP: 127.0.0.1:34400 But if I look in the web interfaces settings page and click server information, I see the local IP of the machine.

[marcelGoerentz]

Hi, I will investigate this.

[marcelGoerentz]

Interestingly, I just noticed after re-launching my 1.1.15 version that in the log, it states the DVR IP. 2024/08/10 03:08:38 [Threadfin] DVR IP: 127.0.0.1:34400 But if I look in the web interfaces settings page and click server information, I see the local IP of the machine.

There is a bug when showing the DVR IP in the console. The output is using the systems IP address. The system info should always show a valid IP address that is not loop back address.

When you are entering the machines IP address with the port you are using for Threadfin in your browser like this: 192.168.0.116:34400 Are you retrieving a XML file?

[marcelGoerentz]

The listening IPs option is not only for the web interface. It is for every other function, too. So maybe there is a issue in your configuration. I will adapt the description so it will be more clear that this option will restrict all services and not only the web interface.

[Renkyz]

Hi, thanks for the replies. I have listening IP set to nothing in my settings.json (that's just how it has always been for me). I'll share that part of my config here for you to see:

"language": "en", "log.entries.ram": 500, "m3u8.adaptive.bandwidth.mbps": 10, "mapping.first.channel": 1000, "port": "34400", "ssdp": true, "temp.path": "C:\Users\Administrator\AppData\Local\Temp\threadfin\", "tuner": 10, "update": [ "0000" ], "user.agent": "Threadfin", "uuid": "2023-11-9MFQ-X9T1CJ", "udpxy": "", "version": "0.5.0", "xepg.replace.missing.images": true, "xepg.replace.channel.title": false, "ThreadfinAutoUpdate": false, "storeBufferInRAM": true, "listeningIp": "", "forceHttps": false, "httpsPort": 443, "httpsThreadfinDomain": "", "httpThreadfinDomain": "", "enableNonAscii": false, "epgCategories": "Kids:kids|News:news|Movie:movie|Series:series|Sports:sports", "epgCategoriesColors": "kids:mediumpurple|news:tomato|movie:royalblue|series:gold|sports:yellowgreen", "dummy": false, "dummyChannel": "", "ignoreFilters": false

[Renkyz]

I've always ran my Threadfin on the same machine I run my Plex server and just used that machines local IP for everything (192.168.0.116 in my case). The way I load my channels in VLC for testing reasons is by starting a network stream with this URL: http://192.168.0.116:34400/m3u/threadfin.m3u

On your fork of v1.1.15, this works fine and as expected. But on your more recent versions (I've only tried v1.2.0 and v1.2.3) that exact same URL will still load the channels in VLC, but all of them fail to play and I get no log of my client trying to play anything in the web interface.

[Renkyz]

If there are any more relevant details I might be able to provide that you can think of, please let me know.

[Renkyz]

I always thought that the listening IP field was for setting which IP address should be able to access the web interface and that's it, maybe I'm wrong on this?

[Renkyz]

So I tried setting 2 IP addresses in the listening IP field, like so: "listeningIp": "192.168.0.116;192.168.0.100", But when I start Threadfin, I see an error in the log. I tried loading the channels in VLC on the machine with the address ending in .100 and as you can see, it servers the m3u, but still nothing plays. I'm not sure what else to try.

[Renkyz]

I just tried loading the channels on the hosting machine itself using the same URL I always have and also 127.0.0.1 and it fails in a different way, won't even retrieve the m3u channel list.

[Renkyz]

I just restarted the machine in case that was causing an issue but I have the same behaviour still. I'll stop messing around and wait for any troubleshooting diagnosis steps you might have forme to try. All I know is v1.1.15 works fine for me haha.

[marcelGoerentz]

So I tried setting 2 IP addresses in the listening IP field, like so: "listeningIp": "192.168.0.116;192.168.0.100", But when I start Threadfin, I see an error in the log. I tried loading the channels in VLC on the machine with the address ending in .100 and as you can see, it servers the m3u, but still nothing plays. I'm not sure what else to try.

It seems like the IP that you have provided is not used on your machine.

Can you tell me what will be printed if you are running ifconfig / ipconfig?

Nevertheless, if there is no entry in the listening IP option than everything should run fine.

[marcelGoerentz]

I see that you are not using ffmpeg or vlc for buffering. I will check if there is a bug.

[marcelGoerentz]

I see that you are not using ffmpeg or vlc for buffering. I will check if there is a bug.

I've just tested it, and for me it is working without any issues.

I think there ipconfig will give us the answer.

[Renkyz]

The IP definitely is the for the machine I'm using, and I do in fact use FFMpeg for buffering, I've also used VLC before as well.

This screenshot is from my primary PC, the one I usually load my channel list in VLC media player with.

[Renkyz]

I didn't bother sending my entire settings.json file as I have a few playlists and the file is rather long, so I only included the relevant part from the bottom of the file.

[Renkyz]

And here is a screenshot of the IP's from my server machine

[Renkyz]

The web interface is accessible for me via 192.168.0.116:34400/web/ on every machine connected to my local network.

[marcelGoerentz]

Well this shows at least why the failure has been shown.

The web interface is accessible for me via 192.168.0.116:34400/web/ on every machine connected to my local network.

So far so good!

But still no stream is working? Have you tried using one of the URLs from the created m3u file?

[Renkyz]

I have currently reverted back to v1.1.15. All my tests on v1.2.3 without changing any of my settings result in me still being able to retrieve the m3u playlist in VLC, but the channels themselves don't play anything. I will try enable logger in VLC to see what it is saying on v1.2.3.

[Renkyz]

-- logger module started -- main: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. main: playlist is empty access error: HTTP connection failure main error: connection failed: Connection refused by peer http error: cannot connect to 127.0.0.1:34400 access error: HTTP connection failure main error: connection failed: Connection refused by peer http error: cannot connect to 127.0.0.1:34400 access error: HTTP connection failure main error: connection failed: Connection refused by peer http error: cannot connect to 127.0.0.1:34400 access error: HTTP connection failure main error: connection failed: Connection refused by peer http error: cannot connect to 127.0.0.1:34400 access error: HTTP connection failure main error: connection failed: Connection refused by peer http error: cannot connect to 127.0.0.1:34400 access error: HTTP connection failure http error: cannot connect to 127.0.0.1:34400 -- logger module stopped --

[Renkyz]

This must be because on v1.2.3, the DVR IP is set to localhost. But on v1.1.15, it is set to the local IP assigned by my router to that machine (192.168.0.116), as shown in my very first screenshot I sent at the beginning of this thread.

[Renkyz]

On v1.2.3 it looks like this in the server information.

[Renkyz]

What is even more frustrating is that after closing v1.2.3 and going back to v1.1.15, I have to restart my whole server machine to get it (Threadfin) working again hahaha.

[Renkyz]

A log from VLC while using v1.1.15 and trying to simulate the v1.2.3 behaviour by skipping channels before they can buffer and play.

-- logger module started -- main: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. main: playlist is empty main: Status file authenticated mpeg4audio: AAC channels: 2 samplerate: 24000 avcodec: Using D3D11VA (NVIDIA GeForce RTX 3090, vendor 10de(NVIDIA), device 2204, revision a1) for hardware decoding direct3d11 error: SetThumbNailClip failed: 0x800706f4 -- logger module stopped -- -- logger module started -- main: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. main: playlist is empty access error: HTTP connection failure http error: cannot connect to 192.168.0.116:34400 access error: HTTP connection failure http error: cannot connect to 192.168.0.116:34400 access error: HTTP connection failure http error: cannot connect to 192.168.0.116:34400 mpeg4audio: AAC channels: 2 samplerate: 24000 avcodec: Using D3D11VA (NVIDIA GeForce RTX 3090, vendor 10de(NVIDIA), device 2204, revision a1) for hardware decoding direct3d11 error: SetThumbNailClip failed: 0x800706f4 -- logger module stopped --

As you can see, the IP is now correct and when I stop skipping channels before they can load, it plays just fine.

The issue certainly is Threadfin saying the DVR IP is 127.0.0.1. So all my clients are trying to connect to channels as if their machine was the one hosting them or something like this. Hopefully this is all the information necessary. But I am of course happy to test other settings if you have any suggestions for me.

[marcelGoerentz]

Can you send a picture of the xml that will be retrieved from the browser when connecting to this url: Http://192.168.0.116:34400 Would be great if you could send for both versions then the fix should be easy. Thanks in advance!

[Renkyz]

[Renkyz]

Oops, forgot to include the URL bar in the 2nd screenshot, but I promise it's the same haha. All I did was close my 1.1.15 exe and open the 1.2.3 exe and then refresh the browser window.

[marcelGoerentz]

Thanks, I think this will be an easy fix and I will ping you when there is a new beta where it is fixed.

[Renkyz]

Awesome, hopefully not too much work and thanks very much for your time. I appreciate your fork of Threadfin and the work you have done on it :)

[marcelGoerentz]

Thank you for your kind words! I've pushed a new beta recently. Please check if the bug has been fixed 😄

[Renkyz]

Just tested it and I still have an issue with it but only because I have 2 Ethernet ports on my motherboard I think. Threadfin picked the wrong network adapter and so my DVR IP is now 192.168.2.2 which is my 10 gig port that is directly connected with a Cat 5e cable to my primary PC, which also has 2 ethernet ports. So I suppose I have 2 questions now.

1. Does Threadfin have a setting to let me tell it which network adapter it should be using? (Might be possible with 3rd party tools such as ForceBindIP)
2. How hard would it be to implement such a setting?

I'll try test now with ForceBindIP from the OBS developers and see if I can make that work on startup for when my system reboots.

[Renkyz]

Ok I suppose that ForceBindIP idea was a bit optimistic, hahaha. Unfortunately, Threadfin is still insisting on choosing 192.168.2.2 as the DVR IP, instead of 192.168.0.116.

[Renkyz]

[Renkyz]

Even unplugging that direct link ethernet cable didn't help. I think the only thing that would work is disable that ethernet adapter entirely, but I think I'd rather stick with v1.1.15 if that's the case haha.

[marcelGoerentz]

I guess I will have to add an option where the user can choose the preferred interface. If nothing has been chosen Threadfin will pick the first interface found.

So this is not only a bug anymore and will be an enhancement also.

[marcelGoerentz]

Hey, I think I found a solution. Write your IP in the domain setting. That should do the trick

[Renkyz]

Sorry for the terribly slow reply. I ended up having a really big day yesterday haha. I currently have a user watching TV so I'll try set up a testing environment on a spare PC and get back to you with results ASAP.

[Renkyz]

You sir, are an absolute legend. I just set up the latest stable v1.2.3 (not the beta) on a spare PC of mine and configured it all exactly the same as my primary server, just being sure to change file paths etc to account for now running on a different machine. I first tested without adding my IP to the Threadfin Domain field in Settings as you suggested, just to be sure I had the same behaviour. And sure enough, it said my DVR IP was localhost and although I could retrieve the m3u playlist on my primary desktop, all the channels just kept on skipping and there would be nothing in logs indicating I was trying to play channels. I then set my testing PC's local IP in the domain field, saved the settings and restarted Threadfin. It worked immediately! I can't believe it was that simple! hahahaha. Maybe all you need to change now is add an info-tip to that field in settings or rename it to better describe what it can be used for. I still think the ability for users to choose which interface Threadfin runs on could be useful to some people, but for now I believe for my personal needs, I can move forward with using your latest release and just adding the IP I want to use in Threadfin Domain field. Thanks again! I'll leave this open in case there is anything else that needs discussing further but I'm happy for it to be closed when you are ready as I don't think I have anything else to add now that it's working again for me haha.

[PilaScat]

when I try to restore the old ip (cleaning the entry), it doesn't return to the default one, and this is a problem, could you fix? and probably if docker changes ips, cause this to not update and break

[marcelGoerentz]

If there is only one interface then there is no problem. I guess I‘ve to add an option to select the correct IP. This will take some time to consider the best way and implement it.

[marcelGoerentz]

when I try to restore the old ip (cleaning the entry), it doesn't return to the default one, and this is a problem, could you fix? and probably if docker changes ips, cause this to not update and break

Even after a restart?

[PilaScat]

when I try to restore the old ip (cleaning the entry), it doesn't return to the default one, and this is a problem, could you fix? and probably if docker changes ips, cause this to not update and break

Even after a restart?

unfortunately not

[PilaScat]

for now I solved setting the default ip manually

[marcelGoerentz]

I think I will modify the listening IP option into a form where the user can select single or multiple IP address where the binding will bind on next start. If none of the selected IPs matches the actual IPs found threading will then bind to every address and will inform the user in the log about it.

Sounds this like a possible solution to the issue?

[marcelGoerentz]

I've released a new beta, please tell me your thoughts on it, regarding this feature request. I will add a cancel button so nothing will be saved when closing the dialog.

[Renkyz]

Sounds good. I have some time now so I'll take a look immediately.

[Renkyz]

I don't seem to be able to find the beta for download. I can't remember where I found it last time either haha.

[marcelGoerentz]

Try this link: https://github.com/marcelGoerentz/Threadfin/releases/tag/latest-beta

[Renkyz]

Thanks mate :)