Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[wer]

Bob, I'm afraid I spoke too soon.

The crashing problem is back.  It crashes 100% of the time if the server is in, or changes to, the HTPC-Video zone.  All other zones are fine.

It did work successfully yesterday in that zone, I checked, and nothing has changed since yesterday, so I have no explanation. Nonetheless, the issue is definitely not resolved.

Interestingly, the crash (as I said before) only occurs if "app follows server zone changes" is on.  If I turn that off, there's no crashing. If it's off, I can even use the little control in JRemote to change to the HTPC-Video zone and it does not crash.

If "server follows app zone changes" is on, all works well with no crashing.
If both settings are off, also all is well with no crashing.

So the issue is only with "app follows server zone changes" and only with that one zone.

[bob]

Bob, I'm afraid I spoke too soon.

The crashing problem is back.  It crashes 100% of the time if the server is in, or changes to, the HTPC-Video zone.  All other zones are fine.

It did work successfully yesterday in that zone, I checked, and nothing has changed since yesterday, so I have no explanation. Nonetheless, the issue is definitely not resolved.

Interestingly, the crash (as I said before) only occurs if "app follows server zone changes" is on.  If I turn that off, there's no crashing. If it's off, I can even use the little control in JRemote to change to the HTPC-Video zone and it does not crash.

If "server follows app zone changes" is on, all works well with no crashing.
If both settings are off, also all is well with no crashing.

So the issue is only with "app follows server zone changes" and only with that one zone.

Interesting, can you tell me more about that zone?
If you hover over it you should see the zone ID and Index.
Is it a DLNA zone?
What's the device address if so? Same LAN Network as you MC PC address??
Thanks...

[wer]

It is on the same LAN, it is on the same MC server as all other zones, same lan as JRemote. Zone id 10022, index 5
It is a regular zone, not DLNA.

You have full details on this zone because I sent you my library backup, remember.

[bob]

It is on the same LAN, it is on the same MC server as all other zones, same lan as JRemote. Zone id 10022, index 5
It is a regular zone, not DLNA.

You have full details on this zone because I sent you my library backup, remember.

Nope, I can't track all of the stuff I'm working on in parallel, thanks for reminding me!
I looked through the settings, interesting that particular zone is marked as hidden as well as are several others.
I'm curious about how the app follows the zone change to a hidden zone and how do you change the zone on your PC to a hidden zone??

Code: [Select]

[Zones\\10022]
Player Zone - Shutdown Playback Mode=i:"0"
Player Zone - Shutdown Playback Mode Data=i:"0"
Player Zone - Shutdown Playback State=i:"0"
Player Zone GUID="{43784BFF-1E33-47BD-B423-369DCAACA887}"
Player Zone Hidden=i:"1"
Player Zone Internal Volume Reference Level="1"
Player Zone Loudness=i:"0"
Player Zone Name="HTPC-Video"
Player Zone Named By User=i:"1"
Player Zone Startup Volume="0.8999999761581421"

[wer]

No worries!

I had thought of that a week or so ago myself, and so I tested: it makes zero difference if the zone is hidden or not. That's why I didn't mention it.

That zone is normally activated through zoneswitch, so I usually keep it hidden.  But as part of this troubleshooting process I've had it unhidden, and like I said it doesn't matter.  Zoneswitch activates that zone when a video is played, but of course it then remains the current zone even if the video has stopped playing.  The "HTPC" zone is also part of that zoneswitch rule-set, and the HTPC zone causes no trouble for JRemote.  The other hidden zones you see are either DLNA zones that I don't use, or something exclusively activated via zoneswitch.

If app follows server zone change=on, then JRemote crashes if that zone is the current zone or gets activated.  The means of activation does not matter: JRemote crashes if the zone activates via zoneswitch, and it crashes if I just click on the zone on the server.  If app follows server zone changes=off, no crashing.

[HaWi]

Thanks Bob, I didn't know that.
cheers,
Hans

[jlib]

Can JRemote select between libraries?  I do not see that functionality so just want to make sure that is expected and I don't have something misconfigured.  I can easily switch between my two separate libraries from the Media Center console.  Just to be clear I am talking about completely separate libraries (let's call one SACD and one MP3) and not library views like artist, album, etc. which works fine remotely.  Currently I have to run to the Media Center to change which library is loaded.  Loading one unloads the other.

[maliceme]

I got your crash log.
The crash on first server add is a known bug.
I'm not sure how we will be able to debug your issue of losing connection.
What version of MC are you running on and what platform?
You might turn on logging in MC and see if we can find an event in that log that coincides with the loss of connection.

Checking in to see if you've reviewed the log. I'm still seeing this behavior (JRemote loses connection to the server after about 1 song.) I am noticing that this happens when I'm playing back a Smart List, but not when playing back an album.

[bob]

Can JRemote select between libraries?  I do not see that functionality so just want to make sure that is expected and I don't have something misconfigured.  I can easily switch between my two separate libraries from the Media Center console.  Just to be clear I am talking about completely separate libraries (let's call one SACD and one MP3) and not library views like artist, album, etc. which works fine remotely.  Currently I have to run to the Media Center to change which library is loaded.  Loading one unloads the other.

There isn't a way to do that in JRemote at this time.

[bob]

Checking in to see if you've reviewed the log. I'm still seeing this behavior (JRemote loses connection to the server after about 1 song.) I am noticing that this happens when I'm playing back a Smart List, but not when playing back an album.

I didn't see anything obvious in it.
What kind of smartlist? Are there things dynamically coming and going in it during playback?

[maliceme]

I didn't see anything obvious in it.
What kind of smartlist? Are there things dynamically coming and going in it during playback?

I've tried mulitple smartlists. Nothing too fancy. Here's an example:

[Date Imported]=<31d [Media Type]=[Audio] [Last Played]=>30d [Rating]=0 ~nodup=[Album] ~sort=Random

I'm not sure what you mean by "things dynamically coming and going in it during playback". Sometimes I will rate a song on JRemote during playback, but I've tested to see if that makes a difference and it doesn't seem to be a variable. JRemote will lose the server connection whether or not I touch the app during playback.

This morning I've played two albums with no issues, including when I rated songs during playback. I also tried two Smart Lists (including the one above), and both disconnected within one or two songs.

[HaWi]

Is this on a LAN or Cellular network? I just now playing a Smartlist from my iPhone on the LAN and there is no issue. I'll try a few more.

[maliceme]

Is this on a LAN or Cellular network? I just now playing a Smartlist from my iPhone on the LAN and there is no issue. I'll try a few more.

I'm currently on a LAN. The PC is connected via ethernet to the router. Regardless, I see this behavior over both LAN and cellular.

As a comparison, I can run PlexAmp all day long without any dropouts.

[xeroian]

That was a tricky one.
The new HDTracksDownloader is putting the MDAT atom before the MOOV atom which has the size details and is at the end of the new HDTracksDownloader ALAC files.
This causes the decoder in JRemote to barf, it can't handle that case.
So, either HDTracks should fix that OR you can re-encode the files back to ALAC on MC to fix them.

All kudos for tracking that down. I don’t think I have the clout or credibility to tell HDTracks that they shouldn’t put the MOOV after the MDAT so I guess I will be doing some re-encoding. At least I can still keep everything in ALAC though.

Alternatively does the old JRiver-written HDTracks downloader still work?

Thank you for the update.

[HaWi]

I'm currently on a LAN. The PC is connected via ethernet to the router. Regardless, I see this behavior over both LAN and cellular.

As a comparison, I can run PlexAmp all day long without any dropouts.

I wonder if it could have anything to do with audio resolution. Are any of your files hi-res? I have had issues with those before I changed the settings to automatically downsample to 44.1kHz

[maliceme]

I wonder if it could have anything to do with audio resolution. Are any of your files hi-res? I have had issues with those before I changed the settings to automatically downsample to 44.1kHz

Many of the files are hi-res, although JRemote is set to convert them to mp3.

I also just played a playlist (not smart list) of 10 songs with no problems. The playlist included a combination of standard resolution flac files as well as hi-res files (including 24/88.2, 24/96, and 24/192). So it looks like only smart lists are causing the problem.

Interestingly, even if the output of the smart list is a single album, the server disconnects. I just played this smart list, and the disconnect occurred during the first song.

[Media Type]=[Audio] -[Album]=[] ~limit=1,-1,[Album] ~sort=[Track #] ~limit=1,-1,[Album Artist] ~sort=[Disc #],[Track #]

[bob]

All kudos for tracking that down. I don’t think I have the clout or credibility to tell HDTracks that they shouldn’t put the MOOV after the MDAT so I guess I will be doing some re-encoding. At least I can still keep everything in ALAC though.

Alternatively does the old JRiver-written HDTracks downloader still work?

Thank you for the update.

I don't know if you can still use the old downloader.
I can however point you to the post on the issue at the support board from whence the plugin comes.
It is going to be an issue for them in a lot of situations like this. The MOOV atom really shouldn't be at the end.
https://www.un4seen.com/forum/?topic=10910.msg132657#msg132657

[bob]

Many of the files are hi-res, although JRemote is set to convert them to mp3.

I also just played a playlist (not smart list) of 10 songs with no problems. The playlist included a combination of standard resolution flac files as well as hi-res files (including 24/88.2, 24/96, and 24/192). So it looks like only smart lists are causing the problem.

Interestingly, even if the output of the smart list is a single album, the server disconnects. I just played this smart list, and the disconnect occurred during the first song.

[Media Type]=[Audio] -[Album]=[] ~limit=1,-1,[Album] ~sort=[Track #] ~limit=1,-1,[Album Artist] ~sort=[Disc #],[Track #]

Ok thanks for the info, will take a closer look when time permits.

[HaWi]

[Media Type]=[Audio] -[Album]=[] ~limit=1,-1,[Album] ~sort=[Track #] ~limit=1,-1,[Album Artist] ~sort=[Disc #],[Track #]

Just played this exact Playlist with a couple of random albums without issue.

[maliceme]

Just played this exact Playlist with a couple of random albums without issue.

Hope you deleted the redundant ~sort=[Track #]  that was in my original! NOT elegant!

[HaWi]

Hope you deleted the redundant ~sort=[Track #]  that was in my original! NOT elegant!

I actually didn't because I wanted to reproduce exactly what you did. Also, I know so little about the syntax to generate smart lists that I didn't even notice...

[maliceme]

Ok thanks for the info, will take a closer look when time permits.

Some additional follow-up. I used MO 4Media to connect to the same server and play a selection of smart lists. No problems. So, I don't think the issue is with my network or my server hardware.

[goatherder]

Minor question: Is there a way to prevent it auto-resuming playback when you go back into the app?

[wer]

Bob, any news on the crashing?  Thanks!

No worries!

I had thought of that a week or so ago myself, and so I tested: it makes zero difference if the zone is hidden or not. That's why I didn't mention it.

That zone is normally activated through zoneswitch, so I usually keep it hidden.  But as part of this troubleshooting process I've had it unhidden, and like I said it doesn't matter.  Zoneswitch activates that zone when a video is played, but of course it then remains the current zone even if the video has stopped playing.  The "HTPC" zone is also part of that zoneswitch rule-set, and the HTPC zone causes no trouble for JRemote.  The other hidden zones you see are either DLNA zones that I don't use, or something exclusively activated via zoneswitch.

If app follows server zone change=on, then JRemote crashes if that zone is the current zone or gets activated.  The means of activation does not matter: JRemote crashes if the zone activates via zoneswitch, and it crashes if I just click on the zone on the server.  If app follows server zone changes=off, no crashing.

[bob]

Bob, any news on the crashing?  Thanks!

Not yet, I've been working on the Mac build pretty exclusively the last week.

[bob]

Attn beta testers, there is a new beta available with the following fixes (in addition to the ones in the previous beta).

Fixed stale playing now playing info when content changes on the server independently of JRemote.

Fixed crash on initial connection to a server when the server database is empty.

Fixed crashes when loading zones if app follows server and there are hidden zones with an index of the current zone > than the total number of non-hidden zones.

[xeroian]

Bob, I am getting huge dropouts and corruptions using 3.33 build 388 to play on my SE running iOS 14 beta 1 and a 6s plus running iOS 13.5. Completely unlistenable but JRemote 3.32 still runs perfectly on my X running iOS 13.5. Server is running final build of JRiver 25.

Ian

[bob]

Bob, I am getting huge dropouts and corruptions using 3.33 build 388 to play on my SE running iOS 14 beta 1 and a 6s plus running iOS 13.5. Completely unlistenable but JRemote 3.32 still runs perfectly on my X running iOS 13.5. Server is running final build of JRiver 25.

Ian

What are your transcoding settings in each case as well as the source material format?
I use an SE all the time and it works great (with MC26 at any rate).

[HaWi]

Build 888 doesn’t log in anymore and won’t wake the iMac from my iPad (iOS 13.5).
The previous build works just fine on my iPhoneX (iOS 13.5).
Tomorrow, I’ll try to set up a new server and see if it works again.

[xeroian]

What are your transcoding settings in each case as well as the source material format?
I use an SE all the time and it works great (with MC26 at any rate).

No transcoding and 96/24, 48/24 and 44.1/16 ALAC.

But I think I have solved the problem. Last night when testing I let TestFlight “overwrite” 3.33 build 338 with build 388 and this may have caused the problem.

Today both devices were still producing garbage so I deleted build 338 and installed the standard 3.32 release. Both iPhones worked fine. Then I asked TestFlight to overwrite with build 388.

That produced unusable apps on both devices. As soon as I invoked JRemote it crashed to the iOS home screen. 

So I deleted the app so that TestFlight could do a clean install. Build 388is working fine at the moment on iOS 13.5 and IOS 14 beta 1.

Regarding HaWi’s problem I just wanted to confirm that I can still wake and shutdown my Windows 7 PC.

[HaWi]

On my iPad, I can now sometimes get it connected by opening settings and pressing the ‘i’ (Info) icon. When connected it’s doing fine.

[bob]

It's quite possible that the changes in the database are too different from previous builds.
Oddly enough, when I went back and forth from testflight to the release version on my phone it USE to warn that the data might not be compatible and that I might lose the DB. That was often the case. I haven't seen that for quite a while now.

It's probably best to uninstall JRemote if you run into this issue as xeroian says and re-add your server(s).
I'd like to try to force JRemote to do that with the next release but I've not figured out how yet.

[bob]

Just put out another Beta for 3.33.
It will allow playing the items under the streaming menu to remote zones (not the device zone however) and provides visible feedback on the channel selection.

[HaWi]

Works as expected, with a little delay at start. Any chance Streaming to the device could be made possible?

[bob]

Works as expected, with a little delay at start. Any chance Streaming to the device could be made possible?

Perhaps but that requires changes in MC.

[bob]

One last beta (390) and I'm going to post 3.33, probably on Monday, for sure it will take them a few days to approve it.

There are still going to be some outstanding issues (centering on devices > iOS 11 is one that I'm on the trail of) but there are a lot of fixes from 3.32 and a new feature to get in.

[HaWi]

Just tried out 390 and it works perfectly. One thing that still bugs me is that JRemote doesn't honor linked tracks. In MC on the iMac I can, for example, scramble my 'Violin Concertos' Playlist and it will perfectly scramble it by "composition" because the tracks are linked. However, in JRemote, this doesn't happen. Playing the same list scrambled will scramble by track and not by links. I would be very grateful if this could be fixed. Without this capability, it isn't really feasible to use JRemote for playing  classical music remotely.
cheers,
Hans