Print

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

[theriverlethe]

I'm trying to use JRiver MC26 on Windows 10 as a DLNA renderer for DSP processing to headphones. JRiver works fine as a DLNA controller/server, but whenever I try to play to JRiver as a renderer, the file appears briefly in the playlist and disappears. I've tried Logitech Media Server and Foobar2000 as controllers. Any ideas?

[RoderickGI]

MC is a pretty well behaved DLNA Renderer, when everything is setup and running correctly.

If you are sending from a third part DLNA Server, using a third party DLNA Controller, MC should apply the DSP you have set in Audio options correctly. Sometimes (usually, but not always it seems) you may need to stop playback and restart it to have changed DSP settings applied. But if you have the DSP all set up, and start playback using a Controller, MC should work fine.

I'm assuming that your headphones and wired, and not Bluetooth or something else.

Having the file briefly appear and then disappear sounds like the files is received, and then passed on to something that isn't managing the stream, so it just such it all up at once, and maybe does nothing with it. The DLNA Server will have more control over how the MC DLNA Renderer behaves, based on the information the Server sends. At least I think that is the case.

So I guess, explain more about what you are doing.

[theriverlethe]

MC is a pretty well behaved DLNA Renderer, when everything is setup and running correctly.

If you are sending from a third part DLNA Server, using a third party DLNA Controller, MC should apply the DSP you have set in Audio options correctly. Sometimes (usually, but not always it seems) you may need to stop playback and restart it to have changed DSP settings applied. But if you have the DSP all set up, and start playback using a Controller, MC should work fine.

I'm assuming that your headphones and wired, and not Bluetooth or something else.

Having the file briefly appear and then disappear sounds like the files is received, and then passed on to something that isn't managing the stream, so it just such it all up at once, and maybe does nothing with it. The DLNA Server will have more control over how the MC DLNA Renderer behaves, based on the information the Server sends. At least I think that is the case.

So I guess, explain more about what you are doing.

I disabled all DSP for troubleshooting, so it has nothing to do with that. I'm using the WDM driver, so is it possible the IPC stream is knocking out the DLNA feed for some reason? This happens on both PC's I'm trying to use as renderers.

[theriverlethe]

I disabled the WDM driver and rebooted, to no effect.

[theriverlethe]

I got it to work - LMS' UPNP plugin has a predefined profile for JRiver.

[theriverlethe]

It appears JRiver's DLNA renderer just doesn't support FLAC for some reason.

Edit: This is probably also why Qobuz doesn't work from LMS, which was the entire reason I tried to set this up in the first place. (It works great with a four year-old Denon receiver.)

[JimH]

MC works fine with FLAC when using DLNA.

Please describe your setup in detail.

[theriverlethe]

MC works fine with FLAC when using DLNA.

Please describe your setup in detail.

Sure, I have a Debian box running Logitech Media Server streaming music to various ChromeCast and DLNA devices. After enabling DLNA in JRiver on my Windows 10 desktop, I'm able to stream FLAC from JRiver to my Denon receiver fine without conversion. However, when I use LMS as the controller and JRiver as the renderer, FLAC files won't play on the desktop unless I force conversion to PCM in LMS. Also, JRiver's renderer only seems to work with "plain 24-bit" and not "packed type-1."

Edit: I should probably point out I'm using MC 26.0.80 and Windows 10 2004.

[JimH]

If you've got non-standard FLAC files (and 24 bit is at least not common), that could explain what you're seeing.

Try some 16 bit stereo FLAC files, just to see what happens.

Try using MC's Panel to play FLAC on JRiver from the LMS.

[theriverlethe]

16-bit FLAC files don't work over UPNP when pushed from Foobar2000 or LMS. Foobar2000 also plays fine to the JRiver renderer if the file is converted to WAV. Unfortunately, neither program has a browsable server - they only work as controllers. All files work fine with JRiver when played locally or streamed from SMB.

Here's a log of Foobar2000 trying to output 16-bit FLAC to the JRiver Renderer (HydraV):

[theriverlethe]

It appears to be an issue with how the renderer is handling time synchronization with FLAC files rather than FLAC itself. From the foobar2000 config file:

# Default to FLAC not supported even if the device claims otherwise
# Many report that they support FLAC yet fail to play an infinite length FLAC stream
supports-FLAC=false

I was able to get LMS to play single FLAC files if I set HTTP mode to "fixed" in the UPNP plugin streaming options. However, the renderer isn't able to advance to the next track at all, even if I disable gapless playback.

[RoderickGI]

I just played a 24 bit 192 kHz FLAC file from my phone running BubbleUPnP to MC acting as a Renderer. Worked fine, as expected.

I play 16 bit 44.1kHz FLAC files to MC acting as a Renderer all the time. no problems.

This is the problem.

# Many report that they support FLAC yet fail to play an infinite length FLAC stream

MC requires the CONTENT-LENGTH descriptor/metadata to be provided by the DLNA server to the DLNA Renderer, as per the DLNA standard I believe. If it isn't provided, MC won't play, I believe. That is consistent with the messages in your LMS log.

[UPnP] Returned time: 0:00:00
[UPnP] Transport state: TRANSITIONING
[UPnP] Returned time: 0:00:00
[UPnP] Transport state: TRANSITIONING
[UPnP] Returned time: 0:00:00

AndrewFG or Bob can probably explain.

Search for posts in the forum about "CONTENT-LENGTH" if you wish to learn more.

Also, JRiver's renderer only seems to work with "plain 24-bit" and not "packed type-1."

That seems to be something specific to Squeezebox, and by extension LMS. Google doesn't have much to say about it. Do you have a reference for it?

[theriverlethe]

Both Foobar2000 and LMS implement DLNA this way and the Denon receiver has no issue with it. Regardless of "official" standards, it appears to be common practice. Even my LG television handles it without issue.

As far as packed 24-bit, I suspect it's just differential PCM. The LMS notes mention DVD audio, but if transcoding isn't enabled, LMS is serving the files unaltered anyway.

Edit: Also, I should clarify that the log is from Foobar2000 UPNP plugin, not LMS. LMS' log provides no useful output.

Edit 2: Using the "HTTP: fixed" output method, the 24-bit FLAC plays fine in JRiver. LMS must've defaulted to packed 24-bit when I disabled FLAC output for the JRiver renderer.

[AndrewFG]

Edit: Also, I should clarify that the log is from Foobar2000 UPNP plugin, not LMS. LMS' log provides no useful output.

IMHO the log from FooBar also provides no useful content either.

Edit 2: Using the "HTTP: fixed" output method, the 24-bit FLAC plays fine in JRiver. LMS must've defaulted to packed 24-bit when I disabled FLAC output for the JRiver renderer.

So you are saying that you have solved your problem? Or?

[theriverlethe]

IMHO the log from FooBar also provides no useful content either.

So you are saying that you have solved your problem? Or?

No, the DLNA renderer still doesn't work with FLAC from LMS or Foobar2000. The 24-bit issue resulted from accidental conversion to an unusual PCM format in LMS.

[AndrewFG]

Do you know WireShark? If so can you please run a trace of the HTTP traffic between the server and the renderer?

[theriverlethe]

Not really, but I can certainly try. I set "host 192.168.6.142" (the server) as capture filter, but you'll have to apply a display filter for http.

[AndrewFG]

Not really, but I can certainly try. I set "host 192.168.6.142" (the server) as capture filter, but you'll have to apply a display filter for http.

Thanks for the capture. I can see UPNP commands where the Control Point is polling the Renderer’s state (GetTransportXx & GetPositionXx), as well as adjusting the volume (SetVolume), but critically the capture does not include the commands where the CP gives the Renderer an URL to be played (SetAVTxxx) or then issues the actual play command (Play). So unfortunately I can’t tell you what is going wrong. => Could you please try again, but this time capture around the time when you actually send a command to play a track?

[theriverlethe]

Alright, here's take two. I shut off the JRiver renderer output in LMS before starting the trace, cleared the play queue, turned the JRiver renderer back on in LMS, and attempted to play a locally stored FLAC album.

[RoderickGI]

Interesting.

I can see the Renderer (MC) requests the Cover Art, which is then sent. That happens twice in fact (Lines 23 & 50). Same Cover Art file. I note that it is sent in chucks at the maximum MTU of 1514 bytes.
I can see the Renderer (MC) requests the "bridge-7.flac" file (Line 24), but it doesn't ever seem to be sent.
Then there is one packet responding to the request for the file at 13.720695 seconds (Line 102) when the server sends a "Continuation" packet?

Also, no SetAVTxxx or Play commands.

The second Cover Art send finishes at 7.777696 seconds, and the log finishes at over 103 seconds, so the flac file should have been sent by then.

Beyond that, I can't see anything interesting. Andrew?

[JimH]

Rod,
You're at risk of becoming a DLNA guru. 

Jim

[RoderickGI]

Scary! 

[theriverlethe]

Here's a trace of LMS playing to the Foobar2000 DLNA renderer plugin for comparison. (No, I'm not trying to run both renderers at the same time.)

[RoderickGI]

You need to play from LMS to Foobar2000. That log is only about 37 seconds long, and I still can't see the flac file being sent to the Renderer in it, let alone playback. I see the request to send, but no response to that at all.


I could be wrong. Andrew is the actual DLNA expert, while I am but a pretender. 

[theriverlethe]

The entire sequence should be there, since I cleared the playback queue in LMS before starting the capture. Foobar2000 also has a well-behaved WASAPI output plugin that I'm using with JRiver's WDM driver at the moment. Obviously not the most elegant solution...

[RoderickGI]

The WDM Driver isn't relevant to a discussion on DLNA functionality. Unless there is some significant bug that makes the WDM Driver break the DLNA Renderer functionality. But no-one else is reporting that at the moment.

For that last test, are you saying that you used LMS as the DLNA Server and Controller, and sent a flac file to the Foobar2000 DLNA Renderer plug-in, acting as a DLNA Renderer, and the flac file played correctly? You heard the audio output from Foobar2000?

All in the 37 seconds included in the log you provided?

[theriverlethe]

That’s correct - about 20 seconds of music playback to Foobar2000 on the desktop, several more seconds for the Wireshark UI to respond after stopping playback... Likely also includes the HTTP traffic to LMS’ web UI to start and stop playback.

Capture filter was “host 192.168.6.142 and host 192.168.6.238.”

[RoderickGI]

Well, there is a large transfer from the server to the renderer, but it appears to be identified as a log file, rather than a FLAC file. Maybe it is obfuscated for some reason.

We shall have to wait for Andrew to have a look.

[mattkhan]

the repeated log output is just some UI view by the looks of it, if you view that in wireshark then follow the "Reassembled PDU in Frame" link and it will then show you the complete output which is just a load of html

my guess is that playback is packet 356 which hits bridge-2.flac on port 49153

google suggests this is something called CastBridge https://forums.slimdevices.com/showthread.php?104614 so not sure what that has to do with DLNA (or perhaps that is the point, user needs to
 use some other protocol to get it to work?)

[AndrewFG]

Here's a trace of LMS playing to the Foobar2000 DLNA renderer plugin for comparison. (No, I'm not trying to run both renderers at the same time.)

Many thanks for the trace. Here is what it tells me..

• The control point does a POST #SetAVTransportURI (for bridge-7.flac) command and MC acknowledges with HTTP 200 OK
• MC acknowledges the SetAVT also by sending a NOTIFY with the accepted track meta data
• The control point does a POST #Play command and MC acknowledges with HTTP 200 OK
• MC does an HTTP GET for the cover art, and the server delivers it with HTTP 200 OK
• MC does an HTTP GET for the track /bridge-7.flac and the server responds with 5 bytes ("0"<cr><lf><cr><lf>)

Everything is working as it should until the last bullet above. The fact that the POST commands and the GET for the cover art succeed indicate that the both server and renderer are online, the router is working, and firewalls are in general allowing HTTP traffic in both directions. The response from the LMS server ("0"<cr><lf><cr><lf>) is completely unexpected; the bytes are coming from the server, so it indicates that the server DID something, but it is neither a valid HTTP success response, nor is it a valid HTTP error response.

This means the error is on the server side. MC is behaving exactly as it is supposed to. If the server does not deliver the track, then it is no surprise if MC cannot play it.

[AndrewFG]

Here's a trace of LMS playing to the Foobar2000 DLNA renderer plugin for comparison. (No, I'm not trying to run both renderers at the same time.)

Ok. I looked at your FooBar trace too. Basically it looks very similar to the trace with MC. The command sequence is ended by a the renderer making a GET for the media, to which the server apparently fails to respond in both cases.

This is the GET request sent by MC.. (the 0 at the end is the server's response)

Code: [Select]

GET /bridge-7.flac HTTP/1.1
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36 Edge/12.246 JRiver_Internet_Reader/2.0 UPnP/1.0
Icy-Metadata: 1
Host: 192.168.6.142:49153
Connection: Keep-Alive
Cache-Control: no-cache

0


EDIT: I looked at the flags that the server set on the data packet containing its (0<cr><lf><cr><lf>) response. Neither the FIN (final) nor RST (reset) flags are set. So this indicated the server did not pro-actively close the socket. It just did not send anything more..

And this is the GET request sent by Foobar (there is NO response at all from the server)

Code: [Select]

GET /bridge-2.flac HTTP/1.1
Host: 192.168.6.142:49153
Connection: close
User-Agent: foobar2000/1.5.4
Accept: */*
Icy-MetaData:1



The only differences of note between the two traces are a) that the GETs are for different tracks (2 vs. 7) and b) the slightly different (but in either case bad) response from the server.


As both @mattkhan and @RoderickGI have observed in the Foobar case there is some other stuff going on between the renderer and the server, but whatever it is, it is not a regular HTTP GET response, and does not look like a media file transfer; it is perhaps possible that in the Foobar case there was something else going on that wasn't captured in the WireShark filter; maybe some UDP or HTTPS traffic, or maybe something mediated by a device on another IP address (perhaps a Chromecast thingy somewhere ??)..

Anyway, my summary so far is: You are wrong to blame JRiver MC for this. You need to discuss this with the guys at LMS or FooBar first. Then tell us the answer, and maybe JRiver can do something to help..

[AndrewFG]

PS just out of curiosity, what happens if you paste the track link into your browser?

http://192.168.6.142:49153/bridge-2.flac

[theriverlethe]

PS just out of curiosity, what happens if you paste the track link into your browser?

http://192.168.6.142:49153/bridge-2.flac

It just says "192.168.6.142 refused to connect." I believe the "bridge number" refers to the player LMS is casting to. I can absolutely attest that during the respective traces, Foobar2000 is outputting audio and JRiver is not. The JRiver player appears to get stuck in a loop with the server attempting to restart playback every 4 - 5 seconds.

[AndrewFG]

If FooBar is able to play the track, it has to be getting the media by some means other than what is shown in your traces. And if that is the case, then whatever means it is using, it is definitely NOT UPNP / DLNA.

To be specific there is zero evidence in your traces that either a FooBar or MC are getting the media by direct TCP communication between renderer and server. I can’t help you any more until I know how FooBar IS getting the media.

[theriverlethe]

What other mechanism would the LMS UPNPBridge plugin be using to successfully send audio to Foobar2000, a Denon X3300W and LG television? Can you suggest a different capture filter or settings in WireShark?

[JimH]

You might ask on the foobar forum or the forum for Logitech Media Server.

[AndrewFG]

Can you suggest a different capture filter or settings in WireShark?

Sure. Don’t set any filter. Capture everything you can. Both TCP and UDP traffic. If you are worried about security, then PM it to me, rather than posting it openly here.

[theriverlethe]

Sure. Don’t set any filter. Capture everything you can. Both TCP and UDP traffic. If you are worried about security, then PM it to me, rather than posting it openly here.

I'm more worried about the 3000kb file size posting limit when it captures all the chunks. I'll attempt another trace and try to PM it to you.

[theriverlethe]

I'm more worried about the 3000kb file size posting limit when it captures all the chunks. I'll attempt another trace and try to PM it to you.

PM sent.

[RoderickGI]

Many thanks for the trace. Here is what it tells me..

• The control point does a POST #SetAVTransportURI (for bridge-7.flac) command and MC acknowledges with HTTP 200 OK
• MC acknowledges the SetAVT also by sending a NOTIFY with the accepted track meta data
• The control point does a POST #Play command and MC acknowledges with HTTP 200 OK
• MC does an HTTP GET for the cover art, and the server delivers it with HTTP 200 OK
• MC does an HTTP GET for the track /bridge-7.flac and the server responds with 5 bytes ("0"<cr><lf><cr><lf>)

Andrew, I am using this thread and your analysis to learn a bit more about DLNA conversations and using Wireshark to analyse them. I went back to this log to compare to your analysis, and noticed something that may be an issue.

For clarity, I shall put the packet number at the beginning of my comments. Also, this is referring to the log from here:

Alright, here's take two. I shut off the JRiver renderer output in LMS before starting the trace, cleared the play queue, turned the JRiver renderer back on in LMS, and attempted to play a locally stored FLAC album.

Which is the LMS.pcapng.gz file, which I think is the actual log you were commenting on in your post above.

11  LMS sends the #SetAVTransportURI to JRiver.
13 JRiver acknowledges the #SetAVTransportURI .HTTP 200 OK
14 LMS sends a #SetPlayMode to JRiver.
16 JRiver responds to the #SetPlayMode with a "500 Internal Server Error". The server referred to appears to be the JRiver 26 server. This is strange to me, as JRiver is acting as a Renderer in this conversation.
17 LMS sends a #SetVolume to JRiver.
18 LMS sends a #Play to JRiver.
21 JRiver acknowledges the #SetVolume. HTTP 200 OK
22 JRiver acknowledges the #Play. HTTP 200 OK

Then we get on to the GET commands for the Cover Art and FLAC file.

The #SetPlayMode sets "NewPlayMode" to "Normal", which looks correct. The packet doesn't seem to have anything wrong in it. The response also looks fine, except for the error reported in the Info column, which is included in the TCP Segment Data of packet 15.


So my question is, could the failure of JRiver to acknowledge the #SetPlayMode be the cause of LMS not sending the FLAC file to JRiver? Or would the acknowledged #Play command mean all was good, and LMS should have sent the file?

Sorry to be a pain. This just looked like an issue.


PS: I'm wondering if turning off the MC DLNA Server, and maybe the MC DLNA COntroller, and just leaving the MC DLNA Renderer running would change the result.

[JimH]

PS: I'm wondering if turning off the MC DLNA Server, and maybe the MC DLNA COntroller, and just leaving the MC DLNA Renderer running would change the result.

That shouldn't be necessary.

[RoderickGI]

That shouldn't be necessary.

I know, but I thought it would be worth a try. 

[AndrewFG]

PM sent.

I got your PM with the two traces. Many thanks.

Unlike your previous traces, these two do include the full media download of your flac track.

Interestingly, both MC and Foobar completed a successful GET to download the flac track in full.

Focusing on the MC case, I can see that after receiving the #Play command, MC downloaded the file, and then it did indeed change its state STOPPED => TRANSITIONING => PLAYING => TRANSITIONING => STOPPED. So it was certainly trying to play the track.

In particular, I noticed that LMS sends the flac file using Chunked encoding; this is unusual, but not forbidden. And I think that MC is able to download files in Chunked format. However I recall from about one year ago, that there was some discussion from another user that seemed to indicate that MC has problems with downloading tracks that are both flac and chunked and I am not sure if that issue was ever resolved..

https://yabb.jriver.com/interact/index.php?topic=119386.0

https://yabb.jriver.com/interact/index.php/topic,119420.0.html

PS the difference between the capture file sizes on FooBar and on MC is not relevant; the latter is just recording more other "stuff"..

[AndrewFG]

16 JRiver responds to the #SetPlayMode with a "500 Internal Server Error". The server referred to appears to be the JRiver 26 server. This is strange to me, as JRiver is acting as a Renderer in this conversation.
..

The #SetPlayMode sets "NewPlayMode" to "Normal", which looks correct. The packet doesn't seem to have anything wrong in it. The response also looks fine, except for the error reported in the Info column, which is included in the TCP Segment Data of packet 15.

..

So my question is, could the failure of JRiver to acknowledge the #SetPlayMode be the cause of LMS not sending the FLAC file to JRiver?

You may have a point here too. I will get back to you on this later.

PS apropos your confusion about "500 Internal Server Error" -- in this context the renderer is acting upon UPnP SOAP commands (i.e. responding to those commands); so in this context it is indeed acting as a "server" (aka a "SOAP command server"), but that does not imply that it is a "digital media server"..

[AndrewFG]

^^

SetPlayMode is an optional command that may used to select the playing mode (normal, repeat, shuffle, etc.).

Apparently MC does not support this command on its renderer. Probably the reason is that the normal, repeat, shuffle, actions can be, and usually are, done by the Control Point in its playlist rather than by the renderer.

It is perfectly OK for MC to not support this action. And in that case MC is doing the right thing by replying with HTTP 500 error. However (JRiver guys please note) there IS a bug in the XML payload snippet that MC delivers with this 500 error (see below).

As far as LMS is concerned, it should not get upset about an HTTP 500 error to an optional action. And as far as MC is concerned it should not get upset about sending such a response. => So I doubt that this is the reason why the OP sees the problem that he does.

----

This is the error xml snippet that MC currently sends..

Code: [Select]

<s:Body>
<u:SetPlayModeResponse xmlns:u="urn:schemas-upnp-org:service:AVTransport:1"/>
</s:Body>

And this is the error xml snippet that MC should be sending..

Code: [Select]

<s:Body>
 <s:Fault>
 <faultcode>s:Client</faultcode>
 <faultstring>UPnPError</faultstring>
 <detail>
 <UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
 <errorCode>602</errorCode>
 <errorDescription>Optional Action Not Implemented</errorDescription>
 </UPnPError>
 </detail>
 </s:Fault>
 </s:Body>

[theriverlethe]

Interesting... JRiver doesn't work with any of the streaming options listed in the LMS plugin configuration:

"Streaming options
Options for streaming to UPnP player (see user guide)
- LMS does not provide the file size to be sent. The best HTTP mode is to use 'chunked' but some UPnP players require 'no-length' to be used. Use 'if known' to send size only when using pcm audio and duration is known
- Some players support gapless playback and thus automatically move to next track in playlist. This is automatically detected, but you can force it disabled. Others (e.g. Bose) are totally broken and are stuck toward track end. Use 'force' to force them to move to next track
- UPnP players can use different methods to restart from paused position. If your player does not pause or resume, use this tp force LMS to restart from paused position
see User Guide for more details (really).
HTTP mode
chunked
 Gapless 
Yes
 Seek on resume 
No"

It will play a single file in the undocumented "HTTP mode: fixed," but has trouble advancing to the next track. Seek works on the client (JRiver) side, but seeking from the server's web UI causes playback to fail.

[AndrewFG]

- LMS does not provide the file size to be sent.
- The best HTTP mode is to use 'chunked' but some UPnP players require 'no-length' to be used.
- Use 'if known' to send size only when using pcm audio and duration is known

It sounds like this may indeed be the cause of your problem...

• As a rule MC needs a Content-Length, yet as a rule LMS does not provide one.
• Therefore, as a rule, MC does not really like 'no-length'..
• MC has some support for Chunked, but it prefers not Chunked.
• MC particularly has issues with Chunked and non PCM, which is exactly your case.
• MC is particularly good with Content-Length on PCM, where LMS is apparently also particularly good.

So I have two (or three) recommendations for you; however I suppose that option 3. is probably wishful thinking..

• Set LMS to convert to PCM -- WITH Content-Length
• If you insist on having FLAC -- in LMS try to disable the use of Chunked
• The ideal solution in LMS is i) disable the use of Chunked, and ii) force sending Content-Length

PS for the time being please ignore the topics "gapless" and "seek"; they are valid topics for another discussion, but please let us focus first on just getting the track to play.

[theriverlethe]

I can confirm that PCM transcoded output to JRiver works as you suggest. Sadly, the Qobuz plugin I'm using in LMS doesn't like transcoding for some reason. I've got questions going in three threads on the LMS forum...

[theriverlethe]

• The ideal solution in LMS is i) disable the use of Chunked, and ii) force sending Content-Length

FLAC does work with HTTP_mode=fixed. UPnPBridge then assigns an arbitrary length defined in its config.xml (eg., <stream_length>1000000000</stream_length>). JRiver fails to advance to the next track in a playlist with gapless set to "yes" or "no," but does work with "force." If you're still interested, I can send traces of these modes to see what's going on.

[RoderickGI]

Thanks again for the explanations Andrew.

Some good progress here guys. It would seem this has identified some (more) improvements JRiver could implement in their DLNA functionality.