All connects fine, but no video (1 Viewer)

[Rhys.Goodwin]

It's best to test all the individual server components from the client. So as mentioned in the previous posts:

Check video streaming from the client with VLC:

1.On the server open the TVServer setup and go to manual control. Select a channel and start timeshifting. If timeshifting starts then the TV server probably working more or less fine, move on)

2.On th eserver open your TV server logs (C:\Documents and Settings\All Users\Application Data\MediaPortal TV Server\log) folder and open the streaming server log file. Look for a couple of lines that look like this:

23-01-2007 22:15:50 Stream server: url for stream is
rtsp://192.168.22.100/stream1


3. Open VLC, File>Open Network Stream select RTSP and enter the URl you got from the log file.

4. Streaming should now start! If not then there could be a problem with the client or the network. One thing to watch out for when configuring TVserver is the IP address it is configured to listen on. If you have more that one network adaptor and one of them is not used then TVServer could have defaulted to the wrong one. Go to TVServer setup at the top of the tree Select TV Servers. In the right hand pane select the server and click edit. Make sure that the IP Address is correct. e.g. the IP address that you would normally use to connect to the TV Server PC remotly.

Check that the SQL server is accepting remote connections:
If Streaming Did stat then the problem is most likley with the SQl server. From the client perform the check I mentioned a couple of posts ago. (Setting up an ODBC data source to test the SQL server)

 

[richbayliss]

I am not an expert (by any means) but I would like to offer a suggestion.

Since the SQL server is required to utilise remote connections, why not use a series of WebServices as a means to pass data. Making the server a kind of proxy.

Example.

To schedule a TV recording on BBC1 at 9pm-10pm, invoke the method "RecordChannel(Channel,StartTime,EndTime)"

This way - no SQL config is required, and some testing WS's canbe made to ensure a good connection.

Maybe its just me, but I think that is better than having 2 clients connected to SQL server.

 

[richbayliss]

I know thats a question of Development, not about this issue. I just think the thread gives a good reason to adopt a new comms method.

 

[Rhys.Goodwin]

Wouldn't you need need IIS configured on the server then? Or is a web service created straight out of SQL Server? If so can is be done with Express edition?

 

[richbayliss]

I think you might need IIS - but this isn't really a problem (IIS comes with XP anyway)

The problem with connecting directly to SQL server is that 2 machines can access data symultaniously, which could cause a corruption (one machine running older code etc)

If you expose a set of WebMethods, then the code behind them is controlled by TVengine - not any number of client machines. This would mean a more stable comms routine between client and server.

Obviously other methods exist, but since we are using VS.NET - why not utilise WS, since that is one of its strongest features.

 

[Robertxc]

FIXED.

The problem was with SQL Server (not surprisingly). I had to specify port 1433 as the listening port for the IP address which is being used for TCP/IP connections. A quick retart of the server, and it works perfectly!

 

[richbayliss]

Glad its sorted.

 

[jassy]

Erm, I have a similar problem to that described. Hope you can help diagnose my client connection problem (think that what it is).
VLC works okay. tried testing SQL server connection with ODBC config - works okay.
I can browse the EPG.
BUT, when I click 'TV on', the client mediaportal just seems to hang.
Any ideas on where I should look?
Thanks.
J

 

[nbradford]

I know the reply is a bit late, but I just solved the same problem (connecting from a remote client and MP hung when turning the TV on wheras a VLC connection worked...)

VLC prompted me to enable a firewall exception on the client when I connected to the stream - Mediaportal didnt, but manually creating an exception in the client firewall for MP fixed the problem.

Hopefully someone else can benefit from this...