Testing tools update - and can we list you?

[James Cridland]

Hello,

If you weren't aware, there's a RadioDNS testing tool on our website - you'll find it at

http://radiodns.org/for/developers/testing-tools/

Since I'm doing a few RadioEPG service-following demonstrations at the moment, I've just slightly upgraded this to...

1. Link to the RadioEPG XSI file directly, so you can click on it to view it within the browser

2. Test that this file actually exists, so you can see at a glance whether it is available

3. Allow you to permalink the results

If you're running any RadioDNS services, we'd love to add you to the presets: please do let me know suitable broadcast parameters. (As a reminder - RadioDNS itself runs no directory services otherwise).

95.8 Capital FM is a good example of a well set-up RadioDNS entry, and supports all current applications.

This tool uses the php-radiodns library available from here: http://radiodns.org/for/developers/software/ - thanks to Andy Buckingham for his work on this library.

Shout if I can make this testing tool more useful for others.

//j

[Robin Cooksey]

Hi James,

 

Thank you for updating this – it’s a tool that I find extremely useful, and use regularly.

 

The changes that you’ve just made sound great.

 

I do have one other suggestion for a future change – for RadioVIS, it might be useful if it displays a warning if there is no trigger-time header.

Obviously, it is legal to omit the trigger-time header, but receivers should not then display the slide until there is a later update which does have a trigger-time header.  In the past, I’ve come across RadioVIS implementations which do not send a trigger-time header, so do not display on some devices.

Currently – the testing tools do show the slide, and it’s not immediately apparent that receivers would not display the slide. I think it might be useful if there’s at least a warning – so that it’s more obvious that the slide wouldn’t show up on a receiver.

 

Best regards,

Robin

 

 

--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en

[James Cridland]

That is a very good point... thanks for that thought. I shall attempt to update it later this afternoon to check for the timing instructions.

J

[Robin Cooksey]

Hi James,

 

I had another couple of suggestions for enhancements to the testing tools:

 

a) Addition of input fields for IP streams – e.g. the FQDN and ServiceIdentifier from the ICY/SHOUTcast header.  While this obviously doesn’t involve looking anything up under the radiodns.org domain, the capability to test the SRV entries, and the services themselves would be extremely useful.

 

b) Support for the RadioVIS HTTP transport (i.e. the _radiovis-http SRV record). It would be useful to display whether an SRV record is found, but it would also be great to test fetching the link as well.

 

Cheers,

[Nick Piggott (RadioDNS)]

Hi Robin,

Can I just check the requirement on the IP stream? Do you want to be able to provide a stream URL that the test tool will connect to and extract the header(s) from, or do you just want a field where you can type the FQDN/identifiers in?

Nick

Nick Piggott
Chairperson
RadioDNS Project

http://radiodns.org // @RadioDNS

[Robin Cooksey]

Hi Nick,

 

The facility to enter a stream URL, and have the test tool extract the header from that would be great; but personally I’d find it useful just to be able to enter the FQDN and identifiers.

This would still automate the process of looking up the various SRV records, and connecting to the Stomp server etc – so would be very useful by itself.