I am experiencing a random problem with Mosaic + Network bridge. I am using an USB stick as source. Playing single tracks always works. Playing full albums sometimes stops at the end of a track and the whole play queue is grayed-out saying “not available” on all tracks. I have to delete the queue and start over.
Sometimes only the first track is gray, yet non of the others work.
Sometimes Mosaic loses connection and the bridge is blinking shortly.
I tried an Android tablet (Samsung S2) and an Android phone (Samsung S9), which made no difference.
I have not yet seen this over UPnP.
It is chaotic and unpredictable. The USB stick never gave me any trouble for a long time. It checks out fine with Windows chkdsk. I can’t tell what has changed when it started, an update of Mosaic for example.
In the log-nSDK file I found a section which fits the problem:
20210718 13:12:01.101 [2044.2044] INFO Streamer: setting next media to play, media URI: file:///media/storage/sda1-4C7AAA637AAA4992/Dozer/Beyond%20Colossal/09%20Two%20Coins%20for%20Eyes.flac
25:04:09.882780000 e[335m 2044e[00m 0xb2600 e[33;01mWARN e[00m e[00m basesrc gstbasesrc.c:3481:gst_base_src_start_complete:e[00m pad not activated yet
25:04:09.887820240 e[335m 2044e[00m 0xb2600 e[33;01mWARN e[00m e[00m basesrc gstbasesrc.c:3481:gst_base_src_start_complete:e[00m pad not activated yet
25:04:09.995407040 e[335m 2044e[00m 0x392cf0 e[33;01mWARN e[00m e[00m flacdec gstflacdec.c:282:gst_flac_dec_set_format:e[00m process_until_end_of_metadata failed
25:04:09.997192760 e[335m 2044e[00m 0x392cf0 e[33;01mWARN e[00m e[00m flacdec gstflacdec.c:285:gst_flac_dec_set_format:e[00m Read callback caused internal abort
20210718 13:12:01.243 [2044.1942] ERROR Streamer: No demuxer element
25:04:14.424436720 e[335m 2044e[00m 0x2da550 e[33;01mWARN e[00m e[00m flacparse gstflacparse.c:607:gst_flac_parse_frame_header_is_valid:e[00m Block size is not constant
25:04:14.535536000 e[335m 2044e[00m 0x2da550 e[33;01mWARN e[00m e[00m flacparse gstflacparse.c:607:gst_flac_parse_frame_header_is_valid:e[00m Block size is not constant
25:04:14.635208000 e[335m 2044e[00m 0x2da550 e[33;01mWARN e[00m e[00m basesrc gstbasesrc.c:2391:gst_base_src_update_length:e[00m processing at or past EOS
(nsdk_streamer:2044): GStreamer-CRITICAL **: gst_mini_object_unref: assertion ‘mini_object->refcount > 0’ failed
20210718 13:12:06.076 [2044.2044] INFO Streamer: Media from URI file:///media/storage/sda1-4C7AAA637AAA4992/Dozer/Beyond%20Colossal/09%20Two%20Coins%20for%20Eyes.flac started to play
20210718 13:12:47.775 [2006.2029] INFO PlayLists: Checking item availability for playlist 0
20210718 13:12:47.782 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:47.815 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 1 updated
20210718 13:12:47.832 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:47.861 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 2 updated
20210718 13:12:47.866 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:47.877 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 3 updated
20210718 13:12:47.881 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:47.893 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 4 updated
20210718 13:12:47.897 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:47.913 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 5 updated
20210718 13:12:47.917 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:47.934 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 6 updated
20210718 13:12:47.940 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:47.952 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 7 updated
20210718 13:12:47.965 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:47.976 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 8 updated
20210718 13:12:47.981 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:47.992 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 9 updated
20210718 13:12:47.996 [2006.2029] WARN PlayLists: item URL is not a HTTP(S) URL, skipping fallback check and disabling item
20210718 13:12:48.009 [2006.2029] INFO PlayLists: Leave Database::updateItem: item 10 updated
20210718 13:12:48.014 [2006.2029] INFO PlayLists: Done processing items from playlist with ID 0
Note that the track that triggered the fault plays well normally. It is not a problem with the FLAC data as such.
Replay from a USB flash drive is limited regarding how you can navigate the files and normally only sequential access is possible. The reason is that, unlike other storage options such as UPnP from NAS, there is no computer in a USB stick to manage the commands from Mosaic. See page 10 of your Network Bridge user manual.
The user experience using this method of replay is therefore not the best and it is really just a convenience feature if, for example, a friend visits you and brings some tracks on a drive.
I am unsure from your description what you are doing with the Apple tablet and phone. This may be a format problem ( again see your user manual for the formats usable with the USB input). Direct connection from iOS devoices to NB is via Airplay.
thanks for picking up my problem. The manual says:
Tracks can be selected individually by the app and played in the same way as from a NAS drive
No search feature and no metadata (which is fine by me).
It should at least play a full album uninterrupted. Which it does often, but it breaks down randomly and invalidates the queue. Yesterday I did a reset on the network interface and after that things got so bad, that I had to switch the Bridge on and off. And lo and behold, it was working fine and playing track by track as it should. Therefore, there must be some problem in the software and the logfile gives some indication of this. However, I cannot interpret what exactly is going on there. Only a dCS engineer can understand that stuff. Is there a way to forward the log snipped to an engineer?
Another thing I observed: when the play queue is broken and I delete it, Mosaic loses connection to the Bridge and the Bridge is blinking a few times. In the log I found that the network connection had reset itself. This is actually reproducible and cannot be normal either.
About the tablet and phone. You misread that part. I am not using Apple. I wanted to make sure that it isn’t some Android device incompatibility with Mosaic or network communications problem of one of my devices. As both devices showed the same behavior with Mosaic, I ruled that out.
You would need to have a dialogue in progress with an engineer. Sometimes one of them will pick up on a thread here and request a log if they think that will be of assistance. However this community is mainly communication between us users so if we can’t help it will be necessary for you to make contact with your dealer or local distributor or, if appropriate, with dCS directly.
Where you experience loss of connection then this is virtually always caused by the network settings or sometimes by the network’s physical configuration. If you search the archives here you will find huge amounts of advice. I won’t attempt anything more detailed as I am no expert on networks.
Sorry, yes I did misread what devices you are using.
Ok, I do not have high hopes to get into a dialog with an engineer, to be honest. I wrote to dCS support once about a different matter and never got any answer. Therefore, I was trying my luck here.
The Bridge in general seems like an unfinished product in some parts. They originally planned for a proper USB interface and WiFi. None of that came to life. The important bits of it work great though. dCS seems to have settled with UPNP via cable, which is flawless. USB is kinda-sorta running, but not 100%.
It does, and sometimes they get even displayed. However, there is no way I can select them in Mosaic and confuse the Bridge with it.
The behavior is random and erratic. That’s the problem. There doesn’t seem to be any rule. Sometimes stuff works, sometimes it doesn’t. I am doing the same thing every time.
It means (but I am no expert): the internal flac decoder failed because in the metadata there is a problem. The demuxer (demultiplexer), that tries to split a container with several sorts of files, one of them FLAC, found an element that cannot be demultiplexed, and sent to the right decoder.
So, either the header of the FLAC file is too long, or it contains media elements that are not a audio file. This could be a jpg.
Actually, this message comes with every FLAC track. I pondered over it myself some time.
Why does every track play without problems when I select it alone? If I had constant, reproducible behavior for specific tracks this would be a different issue. But no, every single track works fine alone. In a play queue, however, the replay suddenly ends at a random track and the queue is broken.
The cause cannot be any property of a single FLAC track. Something very odd is going on.
CRITICAL is the highest log level. That normally means something. After this line stuff goes bonkers.
I found this message via Google back in 2015 and could not make sense of it.
Your network bridge uses GStreamer: a pipeline-based multimedia framework that links together a wide variety of media processing systems to complete complex workflows.
Your log file says: processing at or past EOS
From the GStreamer manual:
End of Stream (EOS)
End-of-stream events are sent if the stream that an element sends out is finished. An element receiving this event (from upstream, so it receives it on its sinkpad) will generally just process any buffered data (if there is any) and then forward the event further downstream. The gst_pad_event_default () takes care of all this, so most elements do not need to support this event. Exceptions are elements that explicitly need to close a resource down on EOS, and N-to-1 elements. Note that the stream itself is not a resource that should be closed down on EOS! Applications might seek back to a point before EOS and continue playing again.
The EOS event has no properties, which makes it one of the simplest events in GStreamer. It is created using the gst_event_new_eos() function.
It is important to note that only elements driving the pipeline should ever send an EOS event. If your element is chain-based, it is not driving the pipeline. Chain-based elements should just return GST_FLOW_EOS from their chain function at the end of the stream (or the configured segment), the upstream element that is driving the pipeline will then take care of sending the EOS event (or alternatively post a SEGMENT_DONE message on the bus depending on the mode of operation). If you are implementing your own source element, you also do not need to ever manually send an EOS event, you should also just return GST_FLOW_EOS in your create or fill function (assuming your element derives from GstBaseSrc or GstPushSrc).
If you can find someone to explain you the above, then you (and we) know what is wrong.
I think you could use the help of @Andrew from dCS.
Thanks for digging this up. So, without an engineer who knows the guts of the Bridge software there is little chance to undestand the problem.
The logfile has regularily appearing error messages that don’t seem to have any consequences. We cannot know what to take seriously and what is just noise.
Thank you for raising this issue. This is a known issue with the latest network software version, and is something which will be fixed in a software release.
You are correct, from what I have seen it does not seem to be tied to a particular file type, embedded artwork etc., just to USB playback itself.
My apologies that you have come across this problem, and for any inconvenience caused.
