Casting on your home network

Tunetorch can play music on DLNA and UPnP devices on your home network, that is on network speakers, AV receivers or multi-room systems. The server sends the music straight to the device. Your phone is only the remote control and can go back in your pocket afterwards.

Casting is off out of the box, because it needs a little setting up.

Setting up

You'll find everything you need under Server settings → DLNA.

1. Switch on the main switch

As long as it's off, nobody sees the device selection in the user menu. That's intentional: a server whose network isn't set up shouldn't show a menu that doesn't work.

2. Enter the server address

The Server address for the playback devices field is the most important value. Enter your server's address on the home network there, including the published port:

http://192.168.1.50:5000

Don't use the container's IP, not localhost and not your public domain. The speaker fetches music and cover art itself via this address, and it sits on the home network. The container doesn't know its own address on the home network, which is why you have to enter it by hand.

Casting doesn't work without this address.

3. Add a device

You add devices by their IP address. Tunetorch works out the rest itself: it asks the device directly, tries the usual ports and paths and reads the name, control addresses and volume range along the way.

One security rule applies: all addresses the device reports about itself must point to exactly this IP. If a device refers to another computer on the network, Tunetorch ignores that reference. Otherwise a manipulated device could get the server to query other addresses. If a speaker only answers with such references, it can't be added. The server log then contains a line with “foreign host” (“fremder Host” in a German log) and one of the codes TT-DLNA-008 to TT-DLNA-011.

If your router gives the speakers fixed addresses, the setup stays stable for good.

4. Grant the permission

Anyone with the DLNA permission may cast (admins anyway); see Users & permissions.

Playing

When casting is active, the user menu has the entry “Play on a device” with the device selection. If you pick a device, playback moves there, and the entry then shows the device's name in its place.

After you switch casting on, the entry appears right away on the device you switched it on. Other devices pick it up once they sync their library, at the latest when you return to the app there.

You can control:

• Play, pause, stop
• Next and previous in the queue
• Seeking within the track
• Volume with a slider (in per cent) and in steps via buttons

The queue stays connected: if you reorder or remove tracks during playback, the device picks up the change.

A queue can have at most 5,000 tracks for the device to take it over. If it is longer, Tunetorch refuses to connect, and you shorten it first. If a change does not reach the device, the app shows a notice with the reason. The device then keeps playing in the previous order. The same goes for pause, seeking and volume — and for the stop when you switch back to your device: if it does not arrive, the app tells you that the device may still be playing.

If someone else is currently using a device, Tunetorch shows that (“in use by …”) instead of taking over the playback that's running.

When the queue ends, the connection stays in place. So you don't have to connect again for the next playlist. If the connection stays unused for a longer time, the server releases it by itself.

Settings per device

These values belong to the device, not to the server. A 2-inch display doesn't need cover art at 800 pixels, and whether gapless transitions work depends solely on the device.

Changes apply from the next playback.

The two volume fields only accept values from 1 to 100. If you enter something else, the nearest limit applies, and the field then shows this limit instead of what you typed.

Format and loudness

If the target format is set to Original, the speaker fetches the original file, and the server doesn't have to convert anything. It has to process the music in two cases:

1. A target format is set for the device (MP3 for new devices), and the file has a different one.
2. Loudness matching is on. Every track then gets a matched copy in the configured target format. If you switch matching on while “Original” is set, MP3 at 192 kbit/s is set, which every device plays. If you want lossless matching, choose FLAC: the copy then keeps the bit depth of the original (16 bit stays 16 bit, 24 bit stays 24 bit), so that speakers that only understand 16-bit FLAC play it too.

If a track is still missing its loudness value, the server measures it and remembers it, just as when playing in the app and the browser. That mainly affects mounted folders, because nothing is measured there when reading in. Each track is measured only once, and after that the app benefits too.

The conversion runs in the background, and the next track is already being prepared while the current one plays. So you only have to wait for the first track at most, where the one-off measurement comes on top. If you don't want to wait until every track has had its turn once, let the Measure loudness maintenance task run once.

The server decides by itself where the short-lived copies are kept: preferably in memory, otherwise on disk. With shm_size you can deliberately put them in RAM (see Installing with Docker).

Controlling access per device

If you like, you can control access for each device separately. If that's off, anyone with the DLNA permission may use every device.

If it's on, two lists apply:

The block list is for the case “one out of five may not use this device”. With the allow list alone you'd have to list the other four, and every account created later would then be locked out without anyone noticing.

Limitations

• Some devices don't show the artist and album. Tunetorch sends all the details, but whether a device displays them is up to its firmware. Closed systems often only show the title and cover art when controlled from outside. Unfortunately there's nothing we can do about that.
• The server and speakers have to be on the same network and able to reach each other.
• Casting needs the internal Redis database. If it fails, casting doesn't work for the time being; everything else keeps running.

Where to go next

• App, PWA & offline
• Troubleshooting