Jump to content

SAT>IP enhancements


userip

Recommended Posts

Hi,

 

I purchased DVBViewer Pro recently because I'm very interested in the SAT>IP protocol. I feel this is a great software.

 

At time, I have two suggestions (more in the future):

 

1) Publish the file "description.xml" as enforces the standard. I try to check the simple discovery sample from http://sourceforge.net/projects/satip/, and it found my hardware SAT>IP server, but with the DVBViewer Recording Service I only show the server, but not the info. Please, can you fix this?

 

2) The second suggestion is add the hardware device "DVB File Device" (as with DVBViewer v5.3.2.0) in the DVBViewer Recording Service. This hardware device is working like a charm! But I like to use also with a SAT>IP client. Please, can you also add this?

 

Thank you for your support, and I hope you continue to improve this good software!

 

Link to comment

Publish the file "description.xml" as enforces the standard. Please, can you fix this?

 

No.

 

IMO there is nothing to be fixed (except in your Sat>IP discovery tool). Simply use your browser to download and display the description.xml, e.g. on the PC where the RS is running by entering the address

 

http://127.0.0.1:8089/description.xml

 

or by clicking the link above :)

Link to comment

IMO there is nothing to be fixed (except in your Sat>IP discovery tool). Simply use your browser to download and display the description.xml, e.g. on the PC where the RS is running by entering the address

 

http://127.0.0.1:8089/description.xml

 

Hi,

 

Thank you for your response! Yes, this URL is accesible. I'll try to search the reason for the problem with this tool (must be a problem with the SSDP discovery protocol).

 

But, related to this file, I found two errors:

 

1) The description not includes the capabilities element (<satip:X_SATIPCAP>) that is mandatory by the standard (see pages 21-22 of the specification version 1.2.1). The server needs to publish the number of tuners, and the type of each one.

 

2) For the http streaming (I don't know if it is supported or not by the RS module) the description needs to include the element of the channel list (<satip:X_SATIPM3U>), as the client can request directly to view a channel using HTTP (see pages 22-23 of the specification document).

 

I hope the developer can improve this file for best compatibility.

 

 

In another order: You agree to include in the next version of the RS the hardware device "DVB File Device"? I feel this will be a must have!

 

Best!

Link to comment
1) The description not includes the capabilities element (<satip:X_SATIPCAP>) that is mandatory by the standard

 

Since the specs are using the term "should" (instead of "must" or "shall") it rather looks like a strong recommendation. Nevertheless I will look after it.

 

2) For the http streaming (I don't know if it is supported or not by the RS module) the description needs to include the element of the channel list (<satip:X_SATIPM3U>),

 

I think this is not correct. First the specs (latest version 1.2.1) say "may be included", so the description does not need to include it. Second it refers to Appendix A that describes M3Us containing RTSP URLs (at least for Unicast, see A2.1: Extended M3U Channel List). So it is no HTTP, but UDP/RTP streaming as used by Sat>IP in general.

 

The RTSP channellist can be obtained with the following URL (on the local PC where the RS is running):

 

http://127.0.0.1:8089/stream.html?aktion=rtspchannellist_m3u

 

I wonder if I can include a "parameterised" URL like this in the description.xml. This would be the easiest solution.

 

However, you may also download a M3U channellist containing HTTP URLs by using the following link:

 

http://127.0.0.1:8089/stream.html?aktion=channellist_m3u

 

You agree to include in the next version of the RS the hardware device "DVB File Device"?

 

No. It will probably happen in future, but it is not at the top of my to-do list.

Link to comment
Hi Griga,


Related to elements <satip:X_SATIPCAP> and <satip:X_SATIPM3U>, I feel that you know the standard very well. So I appreciate if you include these optional elements in the description. I'm sure that the compatibility will be increased. Thank you for listening our suggestions.


In the other part, for me the purchase of DVBViewer is related to network capabilities. I don't use it at all for show video on the PC. The most relevant part (from my point of view) is the SAT>IP server included in the RS module. And the second point in the RS for me is the support for "DVB File device". So for me is a very high priority requirement. Why you can't include it in the RS module? I feel that you have the code and it's working right. So, you only need to "move it" to the RS service. I can accept that you can have a large TODO list with requirements/bugs/suggestions from customers. But, for me this is a very important functionality, the I beg that you can include it in the list, please. I don't try to put it in top most part of the list; only I suggest to include it in the list.


Please, think that this option will provide and impressive flexibility! Moreover, also the "Unicast Network Device" will be included in the RS service (but, for me this isn't a requirement).


Thanks for listening to customers. I'm sure that this software will improve more and more in the future.

Regards.
Link to comment

Why you can't include it in the RS module? I feel that you have the code and it's working right.

Griga is not the original developer of the RS, that was Lars.

So Griga is only familiar with some parts of the source code, where he already had to make changes.

 

And Griga is not only working at the RS, there are the DVBViewer GE, TransEdit, DVBViewer Pro, DVBViewer Filter, answering here in the forum and other smaller pieces. And all of that is not his main job.

So time is the main problem.

Link to comment

 

So time is the main problem.

 

Ok. I understand. I only hope that in time this will be included. Perhaps not in next beta version, but in another version.

 

Thank you for your support! :original:

Link to comment
  • 2 weeks later...

Hi,

 

I'm aware that I need to wait with patience for new functions. Howerver, I like to ask for ETA for the next beta of the RS, because the "fix" of the bug related to the tag <satip:X_SATIPCAP> is relevant for me.

 

Please, if asking for ETA is forbidden in this forum, I apologize for that.

 

Please, continue with the development of the RS as SAT>IP server.

Thank you!

Link to comment

Please, if asking for ETA is forbidden in this forum, I apologize for that.

 

ETA? Do you mean Elvis Tribute Artist? No, that is not allowed here. Put it in Off-Topic ;)

Link to comment

ETA? Do you mean Elvis Tribute Artist? No, that is not allowed here. Put it in Off-Topic ;)

Great Derrick, I never show ETA as "Elvis" but Estimated Time of Arrival ! :D

 

OK. I'll wait with patience. :book::closedeyes:

Link to comment
  • 5 months later...

 

Since the specs are using the term "should" (instead of "must" or "shall") it rather looks like a strong recommendation. Nevertheless I will look after it.

 

 

Hi,

 

Related to the MANDATORY parameter <satip:X_SATIPCAP> that the Recording Service isn't announcing, I like to point to the last Release Notes of the Specification:

http://www.satip.info/sites/satip/files/resource/satip_specification_release_notes_version_1_2_2.txt

 

When in the Section 3.4.1 the sentence "may be included" is changed to "should be included" is for indicating that the parameter is MANDATORY. If the server not inlcuding this parameter, then it is breaking the specifications.

 

Please, fix this soon!

Thank you.

Link to comment

Have you reviewed the Sat>IP Version which the RS announces?

Has there been a RS update since this topic was started?

 

<satip:X_SATIPCAP> and <satip:X_SATIPM3U> are integrated in the internal version.

 

But there is no schedule for a RS release.

Link to comment

Hi,

 

I'm a registered customer, but no one has send me any "new" version! Where is this "new" version in the private zone?

Link to comment

Have you reviewed the Sat>IP Version which the RS announces?

no

Has there been a RS update since this topic was started?

no

 

And it is not possible for you to get the internal Beta version.

Link to comment

And it is not possible for you to get the internal Beta version.

Why?

 

I purchased this software only for the SAT>IP protocol. I'm very interested on it. I can understand that this can not be the same for other customers. Also for some developers. However, I can't understand why not help customers interested on this protocol... Any objective reason for not doing?

 

Regards.

Link to comment

Why?

You are not a Betatester.

(and you can not apply to become Betatester, they are choose from long-time active members in the forum)

 

And about the current development:

http://www.DVBViewer.tv/forum/topic/56400-DVBViewer-540-beta/

http://www.DVBViewer.tv/forum/topic/56510-grabberencodercapture-cards/

 

MadVR fan's had waited for some years:

http://www.DVBViewer.tv/forum/topic/37505-madvr-renderer-in-DVBViewer-nutzen/

 

As I said multiple times time is limited and there are many interests with different priority's.

e.g. the are many people interested in the DVBViewer becoming DPI-Aware

http://www.DVBViewer.tv/forum/topic/56445-ot-vorschlaege-aus-dem-beta-topic/

or people that demand that the developers spend there time answering questions in the forum instead of developing at the software.

http://www.DVBViewer.tv/forum/topic/56497-change-audio-in-preview-mode-of-transedit/?p=428622

 

PS: instead of answering you questions I could have updated 2-10 Wiki pages.

Link to comment

Hi,

 

Thank you for the response and your time!

 

Related to MadVR, I don't understand german, sorry!

 

Related to las beta: the changelog don't includes anything related to SAT>IP protocol. You commented that this problem is already fixed in the internal build. Excelent! Then I hope soon the public beta will include this fix. Specifically because the current implementation of the SAT>IP server contraverses the specifications of the SAT>IP protocol. And for this several clients don't work with the RS. So it's logical that customers hope a solution at some point.

 

Regards!

 

PS: I'm speaking about:

> <satip:X_SATIPCAP> and <satip:X_SATIPM3U> are integrated in the internal version.

Link to comment
×
×
  • Create New...