trivum troubleshooting

Please update to software 9.81 or 10.09 build 17567.

If you configure USBC cable connections with SC344m devices and connect everything correctly, but an error appears:

"Connection is defined, but no real wire is connected"

the reason can be the cable itself. Plug the cable out at one end, turn it 180 degrees, plug it in again. If the cable is just partly damaged, this can help. If it doesn’t help, replace it by a different cable.

Please note that trivum devices require high quality USBC cables:

The playlist contained references to old track ID’s which are no longer available. The software now uses alternative ID’s automatically. Update to the latest software version.

This means the network cable connection is broken. Replace the LAN cable, and/or try a different port at the network switch, then press the reset button on the trivum device.

This means the device software is no longer starting.

Maybe the SD card got loose. Take the device from power, and open it. Remove the SD card (remember it’s orientation). Reinsert the SD card. Reconnect device power.

If that does not help, contact trivum support.

There are small LED’s directly at the power connectors, which are normally off.

If they show a permanent red light it means the power was connected with wrong polarity! Disconnect the power immediately and double check which is the + and which the - cable.

This means the network cable connection is broken. Replace the LAN cable, and/or try a different port at the network switch, then press the reset button on the trivum device.

If the device is blinking in red during startup, and after 1-2 minutes, blinking yellow permanently, this means the device software is no longer starting.

Maybe the SD card got loose. Take the device from power, and open it. Remove the SD card (remember it’s orientation). Reinsert the SD card. Reconnect device power.

If that does not help, contact trivum support.

In some cases a SC311m showed in ServerAdmin tool with an unexpected IP 192.168.99.73, and no longer reacted to any tries to change the network configuration. This probably happened after setting static IP, maybe combined with WLAN activation.

If you can no longer access the SC311m by network, reset the network interface: - press Src and Power together, until the status LED blinks red. Release the keys. - the system will restart, and the network interface is reset to DHCP.

the trivum App for iOS or Android does not list trivum devices in the network.

This is a network problem. trivum devices are found by receiving multicast hello messages. Network components like Router, Switches, or WLAN access points may block these messages.

trivum AirPlay inputs are not listed on an iPhone.

See also: WiFi multicast settings with a Ubiquiti Unify Switch

trivum AirPlay inputs are listed, can be selected at first, but when trying to play audio, it shows a popup "connection not possible".

this occurs if someone else is streaming to the same network input, with a different device.

Company networks are designed for maximum security, including network segmentation

For example, the main company PC’s can be in a VLAN with IP range 192.168.1.x, audio devices in a VLAN with IP range 192.168.2.x, and mobile devices in a WLAN with IP range 192.168.3.x.

By default, security means that every traffic between the network segments is blocked. The mobile devices cannot see Airplay inputs because every UDP message, including Bonjour multicast messages, is blocked between the audio segment and the WLAN segment.

For a comparison, connect a Windows PC by LAN cable to the same switch as trivum. Make sure no WLAN is active, and that it is in the same IP range as trivum. Then install iTunes on the PC. The trivum AirPlay inputs must appear therein.

That means, AirPlay inputs are visible in the same network segment, but not in a different one, e.g. WLAN.

The network administrator must configure exceptions, or bridges, between the segments:

1) Bonjour UDP Multicast queries must be passed from the WLAN segment to the audio segment
2) Bonjour UDP Multicast replies must be passed from the audio segment to the WLAN segment

depending on the firmware running on the network devices (Router, Switch, Controller) this can be achieved by options named "Bonjour", or by directly passing UDP messages for multicast group 224.0.0.251 port 5353. Some WLAN access points like Aruba WiFi AP controller have extra options in their configuration to enable bonjour and airplay messages in the network.

If only case 1) is blocked, there is a workaround option on trivum devices to send AirPlay input names cyclically, even without getting a query. In the trivum web setup, go to: Music / Streaming / AirPlay, and activate: Send zone names repeatedly / send zone names every minute.

But if that does not help, consult the network admin.

Configuring Bonjour bridges may not be sufficient. If the AirPlay inputs are shown and can be selected, but subsequent play fails, then either full UDP and TCP traffic between audio and WLAN segments must be allowed, or the WLAN and audio segment must be joined into the same VLAN.

Further reading:
Spotify Connect inputs cannot be found in the network
trivum App cannot find trivum devices in the network
AirPlay message analysis with sfk.exe

https://www.trivum.com/trivum/docs/en/trivum-faq.html#_airplay_inputs_in_brackets_cannot_be_used

in the Spotify client for mobile phone or tablet, no trivum inputs are visible.

In a few cases this can be a configuration problem, like Spotify Connect not being enabled on the trivum system, or the Spotify App on your mobile was not given the right to look for devices in your network.

But in most cases, it is a network problem: the network is blocking UDP multicast messages.

Also try a restart of the trivum device (ideally from the web configuration). If the network blocks multicast messages only in one way, this can help at least to show the Spotify Connect inputs temporarily.

Further reading:
WiFi multicast settings with a Ubiquiti Unify Switch
SpotifyConnect message analysis with sfk.exe

the trivum music server does not receive any KNX messages. A KNX IP router is not shown in the web configuration.

After a reboot of the trivum device, KNX IP router is visible and listed at trivum. You can select it. You receive some KNX messages.

But after a while, all traffic stops. The IP router is no longer listed as visible. No more KNX messsages are received, until the next reboot of trivum.

This can happen with managed network switches. Most probably, on such a swich

The sense of IGMP Snooping is to reduce multicast traffic: network devices which are not interested in the KNX messages shall not receive it.

But who is interested? That is detected by the Querier. Every few minutes, it sends a question "who wants UDP (KNX) multicast traffic?" to all network devices connected to the switch. The devices must reply like "I want traffic for address 224.0.23.12". The network switch remembers that, and continues sending to those who replied.

Summary: if you configure a network switch,

See also our extended article on network switch configuration:

https://www.trivum.com/trivum/docs/en/trivum-troubleshooting.html#_network_failure_on_group_play

If that does not solve the problem

then maybe you have too many network switches. For example, if your network looks like

then it can happen that multicast and IGMP messages get lost on their way from the IP router to trivum. The switches can no longer decide who asked for which traffic, and whom to send it. Change your network to:

meaning always connect trivum to exactly the same network switch as the IP router.

Note for technical staff: if you are on a linux system, you can listen for active IGMP Queriers by

if a querier is active you will see something like

every few minutes.

When trying to integrate slave devices into the master they are invisible at the master, and therefore cannot be selected.

This is normally a multicast network problem.

The slave devices send hello messages by multicast to all devices in the network. However if there are multiple network switches, they may refuse to pass on such hello messages from switch to switch. Even a single switch may sometimes block multicast messages.

First make sure that the slave devices are really in Slave mode. Open a web browser, open deviceip/setup per slave device. Go into: System / Setup / Master/Slave configuration and make sure that the device is set to slave mode.

Make sure that all trivum devices are connected to the same network switch.

Connect all by LAN cable, never by WLAN.

If there is a managed network switch or router, check it’s configuration if multicast is allowed, and if multicast is always passed between all network ports.

Also try to restart network switch(es) and/or the router. If it works (temporarily) after that consider replacing the network switch by a different model, or connect all trivum components to a separate switch instead of connecting them directly to a router.

Also read the following article about multicast configuration,
No sound on group play with many devices

You have a master/slave system with 5 or more trivum devices.
When playing music in a group, it occurs that there is no sound at some devices, either temporarily or permanently.

This is caused by UDP multicast traffic being blocked by network switches.

Multicast means: one device (with the group play master zone) sends audio packets to the whole network. The target devices which are interested in playing these audio packets listen to that traffic. Multicast may cause highly complex work at the network switches, as they must decide where to send the audio packets to, and where not. It typically fails as soon as multiple network switches are involved.

If you look into the trivum web configuration under

and you see messages like:

then this is the confirmation that multicast IP traffic was blocked. In this example, devices with IP 192.168.1.100 ff did not get their multicast packets, and therefore could not play audio.

By default, the trivum system uses multicast audio automatically as soon as 5 or more devices are in a system. With 2 to 4 devices, it sends audio by UDP unicast, which is very reliable, independent from the switch type used. You can check which mode is used in the web configuration under:

If you restart all network switches to which trivum devices are connected, it is probable that audio will play again, for the moment. Sometimes it may also help to restart the router.
For a more permanent solution, follow these steps:

This way you limit the system to groups playing over a maximum of 4 devices, with unicast audio only. You may also try to allow 5 devices in a group, this may work or not. 6 devices are normally too much, because in this case a group master zone must send the same audio packet 6 times, causing network queue overflows in the operating system.

If these tips do not help, or you strictly want to connect trivum devices to a large managed switch, continue reading the following article.

No sound in some zones, slow controls, blocked network during group play with Installer Line products, or during InStreamer play with Multicast option active.

With this option, audio data in group play is no longer sent by multicast, but by UDP unicast, which should work with every network switch. This works only if not too many trivum devices are part of a group, as it creates a higher load at the master zone that sends the data. It should work safely with 4 devices, for example 4x SC344. It may still work with more devices, so you can just try the option and see if group playback still sounds stable. But, for example, with 10x AudioBox or 10x RP310 systems this option will no longer work. Here you will have to use Multicast and apply Switch configurations as described under 4. below.

The group audio play produces a high network traffic. The IGMP protocol makes sure that this traffic reaches only those devices interested in that traffic. But for this the switch needs to understand IGMP, and the trivum device requires the software version listed above.

Switches supporting IGMP are, for example, HP 1920G, HP-E2620-24-PoEP, Cisco SG300-10.

Furthermore, if the system is controlled by iPads, an Apple Airport Express WLAN access point is recommended.

Example configuration with HP 1920G switch:

First enable IGMP globally. But then you must also click below Operation and set:

Enable: IGMP, version 3, with Querier.

Then select "Save" at the right top to store all settings permanently.

If you think there may be a network loop in your cabling, also enable: MSTP/Global/Enable STP Globally/Enable

If multiple switches are used then care must be taken that either all support IGMP, or that the one supporting IGMP is placed at the top, containing all trivum devices.

So the network should look like, for example:

To avoid flooding of non trivum devices by unwanted audio messages.

With a HP-E2620-24 switch there is only an option "IGMP" by default, without details. It seems that no extra global save option is required. It seems that this switch uses Querier by default. With our tests the IGMP filtering worked immediately. You may also configure details, but for that you need to connect by RS232 cable to that switch. When restarting the switch, to get again to the switch config, you may have to enter it’s IP without any path behind. Same as with 1920G, in case there are still network problems you may enable: Spanning Tree/Tree Management/STP

At a Cisco SG300-28 switch select:

After setting these values, wait 2-3 Minutes before filtering becomes active. Select the blinking "save" button at the top then select: source/running config, destination/startup.

The Cisco also supports STP in case of network loops.

In your Unify switch, go to "Settings / Networks" to get a list of your VLAN’s, for example:

If there is more than one entry, the network is divided into different segments, or VLAN’s.

By default, any multicast traffic between VLAN’s is blocked.

So in this example, trivum devices with IP 192.168.13.x cannot be seen on devices with IP 192.168.1.x, and vice versa.

A mobile phone or iPad in network 192.168.1.x will not list any AirPlay input or SpotifyConnect input of a trivum SC344m or RP341v2 in 192.168.13.x, and the trivum App running on the mobile will also not show these trivum devices.

A KNX IP router in one VLAN cannot be seen by a trivum device in a different one.

In theory, rules can be added to pass multicast traffic between different VLAN’s. But this is beyond this document, and requires a network administrator with detailed knowledge.

trivum may use multicast messages to send audio from a master AudioActuator synchronized to it’s slaves. Depending on the switch used in your network, it may or may not be able to filter multicast traffic.

Make sure to use a switch that supports an option Enable IGMP Snooping. With this option, the multicast messages are sent ONLY to devices that subscribed to this kind of traffic, but NOT to the whole network, like the WLAN. Read all details about switch configuration here: No sound on group play with many devices

AirPlay sound dropouts, which are primarily caused by WLAN reception problems.

→ If music plays well from iTunes via LAN cable, but not from an AirPlay device via WLAN, the problems are caused by bad WLAN reception.

Furthermore, check direct play of music files at trivum. If sound is interrupted with direct music file play, then the problem is not AirPlay related.

1) you allowed a guest to stream Spotify to your trivum system, and after the guest leaves your house, he presses Play on the Spotify app, not knowing that this activates play in your house via internet

2) you gave a family member your Spotify account data, who is out of house, but he selects Play, not knowing that this activates play in your house via internet

3) anywhere in your house is a device (tablet etc.) with Spotify app and your account data logged in, and for some reason play is activated from that

For case 1), go into the trivum setup under: Info / Inspect / Eventlog.

There you should find a clear info at which time what Spotify user played on your system:

If that is not your own user, go to:

then select "limit spotifyconnect play to selected user names", and follow the instructions shown. This way, only your own Spotify user is allowed to play on the trivum system.

For case 2) and 3), if you are unable to find out who is using your account

Then go into the Spotify app on your mobile. Log in again with the new password. Connect again to the trivum system. You will be the only one who can do that now.

Please note: if you stored SpotifyConnect Preset favorites on your trivum device, it is not sure if you can still use them after a password change. Maybe you have to re-create them.

Another solution is to disable zone activation through Spotify Connect.

In the V9 Multiroom Setup, go to:

then select: Zone to activate on network input: No zone control.

With software V10, go to:

and select the gear icon at the streamer, to change the streamer settings. There you find Configure the streamer’s SpotifConnect settings. Therein, select "Show Spotify Connect listener". Setting this option will automatically disable "Show SpotifyConnect speaker 'Zonename'".

This way, the SpotifyConnect input is no longer linked to a zone, and cannot switch it on.

2) create a global action to play Spotify manually:

In the V9 Multiroom Setup, go to:

In the V10 Multiroom Setup, go to:

Then create an action:

Playing Spotify is then done in two steps:

1) In the Spotify app on your mobile phone, select the trivum network input, which now may have a different name, and start playing. Nothing audible will happen at trivum, as the zone is not switched on.

2) Go into the trivum app, into the target zone, and select the "Spotify Connect" action. Now you will hear the sound.

If you see a message "device does not react" then the update data was blocked.

The sound disturbances could be clippings caused by one of the following:

It could be system overloads by excessive tracing.

In the trivum Setup, go to: System / Setup / Advanced.
If the field contains traceplayer=9 then this will internally produce massive trace output, leading to interrupted sound.

Simply clear the field.

Some StreamSource cards delivered in 2014 show the following behavior: * First, everything seems OK, it plays audio. * After a random time, sometimes seconds, sometimes hours the card stops to play audio but no error message is shown anywhere. * The green "C" LED at the card goes off. * Furthermore in the cardlist the card may show a red message Slave inactive.

When trying to use the card an error CardHost inaktiv may appear.

After a full restart of the trivum system, it should work again, until the next error. The reason for this is a change in specifications of a chip on the card, causing incompatibility with V1.30 firmware. You may identify those cards by looking on the biq square chip "LPC2365". In the lowest line, if you see "NSD1317D", with a "D" at the end, then the error may occur (with the older "NSD1317B" revision it should not occur). Even if the number is not 1317 but different, errors may occur - relevant is the "D" at the end.

Or you may send us the card back for repair.

When using 3 cardhosts with many StreamSource cards (STS) and PowerAmpConnect cards (PAC) be aware of the following restrictions:

This means, for example, that sound from STS in slot 1 of 2nd cardhost can NOT be played on a PAC in the first cardhost.

On a C4 system with 2 cardhosts, these restrictions do not exist, so sound from a STS in the 2nd cardhost can be played on a PAC in the first.

If you try to play short music files with less than 15 seconds, it may happen that only a few seconds or even less is played and then the track is repeated or skipped. This also depends on the sample rate used (22 kHz versus 44 kHz).

To achieve correct playback, you may

OR

In the second zone of a slave device, sound drops out every 2 seconds.

Check the configuration for redundant output mappings. For example, if both the first and second zone of the device use the same Cinch output, it causes a conflict.

A source like TV is connected by optical TOS link cable to a trivum device like the AudioBox P150, but only noise is audible.

Disable Dolby Surround at your source. The trivum device can only process plain PCM input via TOS link, but no dolby data.

A source like TV is connected by optical TOS link cable to a trivum device but nothing is audible.

The adapter or digital connection may need to be reset.

It could be sufficient to disconnect the adapter from the trivum device, wait a moment, then reconnect it. If that does not help,

No sound in zones 3 and 4 by using a RP341 or RP340.

If you do a software update to the latest V9 or V10 software, but the error still remains, the fuse may really be broken.

open one cover part of the casing. the fuse directly at the power connector is the relevant one.

It’s a Siba 158000.2,5 oder Littlefuse 045202.5MRL.

RP341v1 uses fuse models with different power:

Littlefuse 0452005.MRL (5A), or Siba 158000.5

XMBC may cause incompatibilities.

Check if AirPlay is working with any AirPlay device, for example AppleTV.

Zone switches on and plays unexpectedly

Look carefully which source is active, and what is played.

You may also look into the system’s Eventlog, in the web configuration under:
Information / About / Show Event Log.
There it tells clearly what event caused switch on of what zone.

Possible activation reasons:

SpotifyConnect play starts, then at trivum the volume is changed.
As soon as the track end is reached, and the next track starts, the volume jumps back to the volume used before at the tablet.

Check your SC device configuration if multiple zones use the same Streamer:

normally Zone 1 has Streamer 1, Zone2 has Streamer 2, and so on.
If, for example, Zone 2 also uses Streamer 1, then the system refuses to send volume changes in a zone to SpotifyConnect as it is amibiguous.

Reconfigure the system to use one streamer per zone exclusively.

A guest or family member X plays SpotifyConnect from his mobile to your trivum device. Then he leaves the house.

Suddenly a zone switches on and plays SpotifyConnect again. This is caused because X forgot to unselect the trivum device in his Spotify mobile app.

To protect against unwanted play, reconfigure the system from instant play to two-step play:

From now, selecting a trivum input in the Spotify app will no longer play music in a zone automatically.

this causes an action "SpotifyConnect" being shown in every zone.

To play Spotify music now, the user needs two steps:

If the SpotifyConnect network input is shown as "Input 1" instead of a zone name, go into the first zone, then touch SpotifyConnect there. If the system has a default setup, "Input 2" will map to the 2nd zone, and so on.

You want to change the volume in the trivum user interface just a bit, but it goes up by itself unexpectedly.

This could be a rare case of special configurations. Go into the web configuration under

and carefully check which control zones are set for which device. The control zone controls volume. With some devices like RP341v1 you have to assign a single zone of that device as control zone. Then make sure that - in a group, no other zone of that device becomes the master zone - you select that zone in your Spotify client, and no zone with a name in () brackets.

Someone else may have used Spotify with an account that is still active in your music system. For more on that, read "Unexpected Zone On with unexpected music play" further above.

Normally an SC device provides 4 SpotifyConnect inputs to the network, but only one can be seen.

Check your SC device configuration if multiple zones use the same Streamer.

If, for example, all zones use Streamer 1 (which makes no sense in most cases) then there will be only one SpotifyConnect input.

Reconfigure the system to use one streamer per zone exclusively.

The trivum device needs configuration data from a DHCP server. A DHCP server gives the device an IP address, and it tells about which Name Server to use. A Name Server is required to connect to the internet for

Therefore make sure that your Router/Switch/Modem that connects your local network to the internet provides a DHCP service which also gives correct Name server information.

A stereo speaker produces damped or massively reduced sound. If you adjust balance to -15 or +15, to hear only left or right, it sounds normal.

Check the polarity of the speaker connection, if + and - are connected correctly both for the left and right channel.

If, for example, the left channel is correct but the right channel has + and - swapped it must cause bad sound, as audio waves from left and right will wipe out each other.

Sound is normal as long as you are near one speaker, but standing in a room between two speakers the sound seems to get wiped out.

Check the polarity of both speaker connections, if + and - are connected in the same way for both speakers.

If, for example, speaker 1 is connected correctly, but speaker 2 has + and - swapped, it must cause bad sound as audio waves from speaker 1 and 2 will wipe out each other.

It is possible that old C4 master computers no longer fully start because the clock battery on their main board is empty.

Connect a monitor and keyboard to the device. See what is happening on startup. A workaround can be to simply press Enter at the keyboard, to have it fully started. If an error about system time is shown, the full solution is to open the device, and to replace the clock battery.

Restart not only the local switch, but also the main router in the network (which makes the internet connection). This may block multicast messages required to communicate with the controller C4.

If you program Crestron to send HTTP commands to trivum it is important that, after each command, the connection must be closed. If you configure Crestron to keep the connection open then it seems to work for a few commands, but suddenly the connection is closed (a forced close by trivum server after some time) and no further communication seems possible, although sending commands by a web browser still works.

The green and red LED of the AudioActuator will stay on permanently with the red LED blinking shortly inbetween.

By default, the device requires a network with a DHCP server to get its IP address. If no DHCP server can be reached, the LEDs behave as described above.

In such a case:

If DHCP is available at least once then the device can be reconfigured to use static IP in the future. See Using static IP for more information. To do so, download and run the trivum Administration Tool (IP Finder) from http://service.trivum.com/

All power connections must be connected, otherwise this error appears.

Look for the Power - + marks on the actuator and connect both sides to the power supply.

The message Zone is undefined appears, if a TouchPad is using an AudioActuator in Installer Master mode. As a result, the AudioActuator’s mode is changed to "Slave".

A direct control of a Slave AudioActuator by TouchPad is not possible. In consequence, the TouchPad loses the connection and zones referenced on that AudioActuator become invalid or undefined.

On the TouchPad…​

This happens only on these steps:

This is a usage conflict. On the trivum side you told that the zone should no longer play. But it is technically impossible to tell the AirPlay client to stop playback. Therefore the iPhone keeps playing.

On the next track change, the iPhone sends another command to start playback, and the zone is switched on again.

The trivum system cannot technically decide which use (from trivum app or AirPlay client) has priority.

If you send AirPlay audio to trivum, do not just stop it in the trivum app. You must always go back to the AirPlay sender device, and stop it there.

If this causes permanent conflicts, you may

and then start AirPlay in two steps:

AirPlay Error: Network (old switch?) uses a unicast .local domain.

This means there is a network configuration that uses a name .local to identify the local DNS domain, which is incompatible to the Bonjour protocol required to use AirPlay. In general this is caused by old router/switch hardware, or wrong configuration within such a switch.

AND/OR

Enter the following at the trivum server:

It will correct some system internal files trying to work around the problem.

The trivum WebUI should be shown within an automation UI web application, which embeds it by an iframe.

When running the automation UI, the iframe only contains an error:
"This content is blocked. Contact the site owner to fix the issue."

Check the HTML code of the automation UI. It may contain something like:

Let’s assume that .100 is the IP of the automation UI, and trivum has IP .200. Then this Content-Security-Policy is not sufficient. It must be extended like:

Things like the Off-button at the right bottom, or Alarm Time changes will not work correctly on a WebTouch Visu displayed on a TouchPanel PC with Windows.

You must configure the correct Pointer Device Click Mode on the TouchPanel PC.

Resource sharing conflict appears if

The trivum system has a technical limitation: archive (playlist) playback and web radio playback are using the same source, a StreamingSource Card.

Therefore switching like Archive Play → Local → Webradio means to switch like StreamSource Card → InputConnect → StreamSource Card and when you’re back to the same StreamSource Card, all it does is to continue in the playback mode that was active most recently - so if Playlist play was active, it will do this, but if webradio was active, it will play the same web radio again.

The distinction Play current stream or run as internet radio on Keypad Keys / Commands applies only when selecting the StreamSource Card for the first time after system restart.

TuneIn tries to auto detect your country by your IP address. If this fails you may enter the latitude/longitude of your city in the trivum server configuration manually.

When updating with a huge version jump, e. g. from 8.16 to 8.47, it may happen that flashing of internal components does not fully succeed in the first step, and this may cause the red LED to be active permanently although the configuration GUI does not show an error.

Repeat the software update (up to 3 times) until the LED goes off after full reboot.

Another reason can be a jammed reset button.

Check if the reset button is somehow locked by the casing. Try to press reset once and check if the system reacts normally.

OR

OR

HINT: Due to the technical reason, the Voltage too low-Alert will appear on all 4 zones even if the voltage is only too low in 2 zones.

In a Homeserver visualization, this command must be called twice to activate a source:

If the volume of a zone is not controlled by the zone itself, for example in case of an AudioBox with independent Line-Out with RTI controlled amplifier, the audio volume of this zone cannot be controlled by the regular group mechanisms.

When using 3 cardhosts with many StreamSource cards (STS) and PowerAmpConnect cards (PAC) be aware of the following restrictions:

This means, for example, that sound from STS in slot 1 of 2nd cardhost can NOT be played on a PAC in the first cardhost.

On a C4 system with 2 cardhosts, these restrictions do not exist, so sound from a STS in the 2nd cardhost can be played on a PAC in the first.

Even if you allowed anonymous network access by "Everyone" to a Windows folder, access is blocked if you leave the username blank.

If you don’t know your workgroup then try to type WORKGROUP, or leave it blank.

If all of the above steps were done, but the music share can still not be accessed:

Multiple Card Hosts are used within a large C4 system.

When playing a source, like analogue input, not only the sound of that source is audible, but also unexpected sound like FM tuner. When disconnecting the analogue in source, only the noise is audible.

A C4 card like FM tuner, Streamsource etc. does not work at all.

Analyze if the problem is caused by the card itself, or by the cardhost, or a specific slot of the cardhost.

If the tests clearly show a defective card then give us feedback so we can arrange a replacement.

You connect an external audio source to the analogue line input. When trying auto sensing there is always a high signal although there is no sound.

Check if "line input volume adjust" is set to more than 0 db. If so, reduce it.

TV is connected by analog audio to trivum, and line input auto sensing is configured. Sometimes line input activates although the TV is off.

1) on the way from tv to trivum there may be electrical interference, like some device switching on or off, inducing signals into the audio line.

2) or the tv is silently switching on temporarily, e.g. for software updates.

If the TV also has a digital output, use that. Replace the analogue line by optical, and directly at trivum, use a digital to analogue adapter, which is available at very low prices. https://www.amazon.com/s?k=d-a+audio+converter

This eliminates the possibility of electrical inductions, and produces an audio signal only if the TV sends a logical "sound is active" signal via the digital line.

Stereo music is playing at normal volume, but whenever there is spoken text, like news or traffic announcements, it becomes very silent.

Check if the + and - wires at one of the speakers were swapped, i.e. "-" of the speaker was connected to "+" at trivum, and vice versa. This could cause centered mono signals like language to be wiped out by inverse sound waves.

An image appears, then the TouchPad freezes for several seconds, then the next image appears.

This happens if the webcam image resolution is far too high, e. g. 1280x480.

Reconfigure your webcam to use a lower resolution.

You can’t control your trivum system while playing audio in a group.

This is relevant with Installer Line products like FLEX, REG, DESIGN (AudioBox).

Please read the following article on software versions and network switch configuration: No sound on group play with many devices

The time is shown only if there will be an alarm within the next 24 hours.

The trivum 4.3" TouchPad WebSetup cannot be opened by a web browser.

Check the TouchPad IP:

If the TouchPad has an IP 169.254.231.13, then it probably failed to get a DNS address from a DNS server.

OR

In such a case, high addresses like .190 are recommended to avoid later conflicts with future DNS servers that typically use low area IP’s.

The trivum TouchPad does not react to touch press in some places of the screen.

Run a touch sensor test:

You get a blank screen. Wherever you touch, it should show a red dot. If there are areas where no red dot is shown, then there is a defect at the touch sensor, and the Touchpad needs to be sent to trivum for repair. To stop the test, touch it with two fingers for five seconds.

The trivum TouchPad does not react to any touch press, but everything else (music status display etc.) seems normal.

A a cold restart (by power disconnect) doesn’t help as well.

Possibly a display connector inside the trivum TouchPad got loose.

The RGB dimmer color wheel is not shown on KNX TouchPad.

If you open the webcam App in the TouchPad’s KNX pages, there is no image.

POE Switches for power supply:

otherwise the power supply is too weak, and the touchpad may start only a few seconds, then switch off.

Problem: when connecting power there is a short white flash, then (with a black screen) background light is active, but (for longer then a minute) no activitiy is visible. Ethernet network LEDs also do not blink.

Solution: look at the LEDs at the network switch where the touchpad is connected. When connecting power at the touchpad, orange should be on permanently, and green should start to blink after a few seconds. If there is no blinking, then the SD card in the touchpad may have got loose during transport. Open the device (by 4 screws) then search for the sd card. Take it out, and push it in again. Then reconnect the device to power. == maximum number of webcams with trivum touchpad

The trivum A13 Touchpad supports up to 8 web cams, with resolution 320x240, and one image update every 5 seconds.

The trivum ARM9 Touchpad supports up to 4 web cams, with resolution 320x240, and one image update every 5 seconds.

If higher resolutions or more frequent updates are used then less web cams will work.

Music purchased through iTunes cannot be synchronized to the trivum System, showing an error file too short, skipping.

Possible reason: If you purchased the music through AppleTV, it is possible that it isn’t synchronized yet to your local apple machine where your music library tracks are stored normally. In this case, you have to synchronize AppleTV manually with your apple server (PC, notebook) to make those tracks fully available for synchronization.

→ A real, complete music file usually contains multiple MB of data.

→ If you see only a very small size (smaller than 32768 Bytes) then this is no valid music file, but either a damaged file, or some kind of reference to a track that trivum cannot use.

In this case, try to play the track in iTunes. If playing succeeds, check the size again - if it’s now several MB, then iTunes did some internal on-demand download action.

If you checked your new files this way, making sure that every track has a reasonable size, you may create a new playlist, drag them therein, then synchronize and check this playlist in the trivum system. The trivum Sync tool will create a statistic for this playlist listing how many tracks were valid for synchronization.

When creating an iTunes database directly on the NAS as described in here then iTunes will store all song information in a file: iTunes Library.xml

If, however, such a file does not exist on a NAS, check this:

System V7: select Addons / Devices / open device, then advanced / verboseMode

Then send test commands: Addons / Devices / open device, select Commands, select Send at the left side.

Then open in the web browser:

If you see messages like:

this means a command was SENT to the Adapter, and the Adapter tried to forward to the device.

If you see messages like:

this means a response was received from the device.

If reponses are listed, however, also depend on the kind of device driver chosen. Unidirectional drivers may never list a response.
In such a case, the following may help:

To do so, find out * the IR/RS232 Adapter IP address * the IR/RS232 Adapter Serial Number * the IR/RS232 Adapter Firmware Version

System V7: IP and SNr are listed under Addons / Devices in the Status column.
Firmware Version is listed under Adapters.

Then download the trivum trace tool from https://www.trivum.com/trivum/docs/de/tools-overview.html

Windows: download trace.exe AND libgcc_s_dw2-1.dll Mac : download trace-mac

Then open a Shell or Command Line Window (e.g. Windows: select Run then type CMD.exe) and go into the folder of the downloaded tools.

Instead of sending commands via trivum to the device, also try to control the device directly, e.g. by switching on a DVD player by it’s power key, then loading a DVD and skipping tracks manually, to produce possible RS232 replies that may show up in traces as described above.

depending on the adapter firmware, more or less informations are shown.

Adapters are detected, devices can be activated by TouchPad or web keypad, but they do not physically react, and errors show up like:

To check if the adapter is physically able to receive any data:

Within the cable, TX/RX lines must be crossed. The pin number for TX/RX is different from device to device. Cable pin layouts on the trivum connector side are documented in http://www.trivum.de/downloads/documents/MusicCenter-V7-Setup.pdf

Excerpt from page 5 MusicCenter-V7-Setup.pdf

Pin 6 of plain RJ-45 will no longer be used in future adapter versions.

The kind of connectors vary from device to device, and even when using SUB-D9 connectors pin assignments can change from device to device. Therefore consult the device manual for an exact pin assignment description.

The TX/RX lines must be crossed.

When measuring the TX line it should show -5 to -9 volts.

'* No longer be available.

If you can send commands to the device, e. g. you press track skip on the TouchPad and a DVD player actually skips to the next track, but you still see the error no valid data on the TouchPad, then since V7.76/8.17 there is also an option in the advanced device settings to disable device reply warnings. This, however, should be used only if you are absolutely sure that the device is connected and reacts to commands. The message device has no connection cannot be disabled. See also Tracing IR/RS232 Adapter communication.

If you have a TIDAL account configured by just entering username and password at trivum, then this is an old method which can no longer play music from November 9th, 2020.

You then have to do these steps:

Spotify accounts configured directly on devices were officially discontinued by the Spotify company on 16.05.2022. If you had this configured, older software shows a wrong error message "need premium account", although the accounts are premium. From Software 9.73 build 16269 there will be a corrected error message: "No service. Please use Spotify Connect."

Therefore use Spotify Connect instead. Install the Spotify App on a music control device, like a mobile device or PC, then select trivum as the playback device. Once music is selected and playback started, there is no need to keep your control device running. E.g. you may close Spotify on the PC, the music will continue to play. However, to change music selection later, you have to run the Spotify app again.

If you prefer accounts directly on the device, a good alternative are TIDAL, Deezer and Qobuz.

With TIDAL, even Family accounts with separate user/password per family member are possible, allowing to configure them all on your trivum device.

With Deezer, this is also possible meanwhile, but it requires an extra step done by through the Family admin account, who has to convert the family member accounts into independent ones, with separate password. Read more here:

https://support.deezer.com/hc/en-gb/articles/206096901-Log-In-To-Deezer-Family

After a System V8 (e. g. AudioActuator) software upgrade to V90, it can happen that music is listed with cover art in the artist/album search, but when playing one of these tracks, the player screen does not show cover art.

Although one reason can be the server which provides the audio, there is one known software issue, which is fixed with V9.82, or V10.10.

Therefore, if you have a software older then that, please update.

Update your trivum system to the latest V9 or V10 software to correct this.

If your system has V8 software, it is highly recommended to update to V9.

If you don’t want to do this, because of C4 device control, you may

then update to V8.85. But be aware that web radio stations may become incompatible again any time in the future, and then fixes may be available for V9 only.

AirPlay produced by iOS9 iPhones or iPads requires at least trivum software version v8.68.

The zone will not switch on unless you update to V8.73 beta build 11441.

Update the trivum app to version 2.6.1.
Please note that right now even app 2.6.1 shows a version 2.6.0 at the bottom of the screen, so refer only to the version shown in the App Store. This will be fixed in the future.

It could happen that there was no sound in slave zones of groups during group play on these devices. Update to V9.63 build 15387 or higher to fix this.

If you want to search, for example, tunein stations, but the text entry field shows no keyboard:

This can happen after activating the app from standby. As a workaround, do these steps:

or update to V9.75 build 16865 or higher.

Make sure you have software 9.74 build 16584 or higher.

If you have a trivum device running with Software V9.74 build 16617 to 16664, and option "Use release software" is not set in the update menu, you will not be able to set that anymore. Trying so creates an error "attribute OptionAlphaSoftware not known". This makes it impossible to update to the latest software directly.

If music selection by touch does not work:

update your system to software V9.50 or higher, where the Web UI was fully reworked.

Update the App to the current version 2.5.1 to fix this.

If you have a trivum system with old V8.x software, control on the iPad by trivum app or Safari web browser may not work. As a workaround, install the Google Chrome browser on the iPad, then enter the trivum IP there.

Since iOS 15.4 it can happen that the WebUI shows a permanent blue bar with connection failure. Update to V8.84 to fix this.

On some devices a touch ob WebUI actions may not do anything. As a workaround, open a Chrome browser on your iPad, then type therein trivumip/visu/iapp

Since V8.53 there is a page print example commands listing command ID’s for external visualisation. Unfortunately, until V8.56 this page documented four internal commands as select TuneIn favorites 1 to 4:

From V8.57 on these commands no longer select TuneIn favorites, but line inputs.

If you use one of these commands, replace them by:

The "@i" syntax however allows to select more than 4 favourites directly.

Full support for static IP is available only from Software Version 8.29. If you update to 8.29 you may have to run the update twice.

To find the static IP settings, follow these steps (V 8.49 or higher):

Find more in the MusicCenter manual here: https://www.trivum.com/trivum/docs/en/mcenter-manual.html#_gira_homeserver_notes

You can check if AirPlay Input announcement messages are visible in your network segment. For example, you may use the command line tool sfk for further analysis.

Then you should see messages like:

which contain a binary data dump, also shown as text.

Please note: make sure the messages contain "_raop" and the expected AirPlay input names. Otherwise they can just be MDNS messages, which are not related to AirPlay.

If you see messages containing "@trivum" with the expected input names, then these are AirPlay input announcements by a trivum server.

If you see no messages at all, but there must be (also non trivum) AirPlay devices in the network, open CMD.EXE as administrator and check your Windows Firewall settings.

If you see far too many AirPlay messages, you may filter like

which will show only messages from IP address 192.168.1.119.

→ The trivum server must send those announcements on restart.

If you see bonjour messages by non trivum devices, but not trivum:
Check carefully if these messages are really AirPlay input announcements, i.e. they contain "_raop" and the expected input names.
Otherwise they may just be MDNS messages, and the other device is also not able to send AirPlay names.

While the Spotify App is in use, you can check if trivum sends Spotify Connect Input announcement messages. For example, you may use the command line tool sfk for further analysis.

IF your PC is connected by LAN cable to the same network switch as trivum, (and ideally it is a simple unmanaged switch like TP-Link 1008P), you will see messages like

In this example, if IP 192.168.1.54 belongs to a trivum device, you see that somehow Spotify Connect inputs are announced by that device. (Exact input names are not visible that way)

If you see no messages at all, but there must be (also non trivum) Spotify Connect devices in the network, open CMD.EXE as administrator and/or check your Windows Firewall settings.

If you see far too many bonjour protocol messages, you may filter like

which will show only messages from IP address 192.168.1.54, or

which will show only messages containing the text "@spotify".