Strange behaviour or bug i would say

[lengis]

Hi,

Long time xbmc user swapping out my backend for Nextpvr (from Mediaportal). I had to scratch my head quite a bit to get it all up and running. On my LAN i use private addresses in the 172.16.0.0/12 range. With this setup my frontend cannot connect to the backend. The weblog says "Not allowing internet based streaming request from: 172.20.x.x". My frontend and backend are on the same /24 subnet.

If frontend and backend are on 192.168.0.0/16 everything works as intended. I didn't have to change addresses on my LAN to verify this since i have a vpngateway running on my backend using the 192.168.0.0/16 range. So if i route the traffic via my vpn (source and destination in the 192.168.x.x/24) it works.

I even tried to change binding order on my NIC without success, still can't connect when on 172.16.0.0/12

Do i really have to change the network address on my LAN to be able to use Nextpvr as a backend? It seems like the Nextpvr is listening on both ipaddresses of my server.

This issue only effects watching live tv, i can browse through the channels and get the EPG.

Br

Lengis, happy to have found a pvr backend that runs on Windows Server 2003!

MVP.log:
[...startup]
2013-01-17 21:59:47.508 [INFO][4] ServiceLocatorThread() Hostname: servern
2013-01-17 21:59:47.524 [DEBUG][3] MVP Service Locator will resolve media port: 6337
2013-01-17 21:59:47.524 [INFO][3] MVP Control thread Listening on port: 5916
2013-01-17 21:59:47.539 [INFO][4] IP Address 172.20.0.180
2013-01-17 21:59:47.539 [INFO][4] IP Address 192.168.249.1
2013-01-17 21:59:47.539 [INFO][6] BOOTPWorkerThread IP Address 172.20.0.180
2013-01-17 21:59:47.539 [INFO][6] BOOTPWorkerThread IP Address 192.168.249.1
2013-01-17 21:59:47.602 [INFO][7] MVP Streaming thread Listening on port: 8337
2013-01-17 21:59:47.602 [DEBUG][7] MVP Service Locator will resolve media port: 8337

Snip from web.log:
2013-01-17 22:01:55.738 [DEBUG][7] Got Web Request (172.20.0.8): /service method=recording.list&filter=pending&sid=36ad5892a0fd4ea681be2cf531ec0f1e
2013-01-17 22:01:55.738 [DEBUG][7] method=recording.list
2013-01-17 22:01:55.738 [DEBUG][7] parameters:
2013-01-17 22:01:55.738 [DEBUG][7] method: recording.list
2013-01-17 22:01:55.738 [DEBUG][7] filter: pending
2013-01-17 22:01:55.738 [DEBUG][7] sid: 36ad5892a0fd4ea681be2cf531ec0f1e
2013-01-17 22:01:55.738 [DEBUG][7] client_ip: 172.20.0.8
2013-01-17 22:01:55.738 [DEBUG][7] host_callback: 172.20.0.180:8866
2013-01-17 22:01:55.738 [DEBUG][7] physical_path: C:\Documents and Settings\All Users\Application Data\NPVR\web\
2013-01-17 22:01:55.738 [DEBUG][7] user_agent: XBMC/12.0-RC3 Git:20130102-7a6cb7f (Mac OS X; 12.2.0 x86_64, Version 10.8.2 (Build 12C60); http://www.xbmc.org)
2013-01-17 22:01:55.738 [DEBUG][7] range:
2013-01-17 22:01:55.738 [DEBUG][7] requested_path: /service
2013-01-17 22:01:55.738 [DEBUG][7] GetRecordingsList
2013-01-17 22:01:55.738 [DEBUG][7] GetRecordingsList@1
2013-01-17 22:01:55.738 [DEBUG][7] GetRecordingsList@2
2013-01-17 22:01:55.738 [DEBUG][7] GetRecordingsList@exit
2013-01-17 22:01:55.738 [DEBUG][7] <?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
<recordings>
</recordings>
</rsp>

2013-01-17 22:01:55.738 [DEBUG][7] <?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
<recordings>
</recordings>
</rsp>

2013-01-17 22:02:12.219 [DEBUG][14] Got Web Request (172.20.0.8): /live channel=4&mode=liveshift&client=XBMC-36ad5892a0fd4ea681be2cf531ec0f1e
2013-01-17 22:02:12.266 [DEBUG][14] StreamNative@1
2013-01-17 22:02:12.266 [DEBUG][14] StreamNative@2
2013-01-17 22:02:12.266 [DEBUG][14] Not allowing internet based streaming request from: 172.20.0.8

[sub]

2013-01-17 22:02:12.266 [DEBUG][14] Not allowing internet based streaming request from: 172.20.0.8

Maybe try setting <AllowRemoteStreaming>true</AllowRemoteStreaming> in config.xml.

[lengis]

Maybe try setting <AllowRemoteStreaming>true</AllowRemoteStreaming> in config.xml.

Thanks a ton Sub, that did the trick

I would still consider this a bug though. 172.16.0.0/12 is private and has to be treated as local, not as internet.

Again, thanks!

Br

Lengis