Closed Schorsch99 closed 7 years ago
therealmuffin
commented
7 years ago Thanks for the report! I've reproduced this issue and committed a fix. If this doesn't resolve your issue, please reopen this issue.
76c2f7286988b5a4a6661353be922fd2d64f7bc7
Schorsch99
commented
7 years ago Thanks for the quick fix! I can't try it tonight, but I'll definetely give it a go tomorrow. :-)
Am 7. April 2017 20:00:11 MESZ schrieb Muffinman notifications@github.com:
I've reproduced this issue and committed a fix. If this doesn't resolve your issue, please reopen this issue.
https://github.com/therealmuffin/synchronator/tree/76c2f7286988b5a4a6661353be922fd2d64f7bc7
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/therealmuffin/synchronator/issues/5#issuecomment-292608524
Schorsch99
commented
7 years ago Hi,
everything working fine now, thanks!
Seems like I was the first one to use the program with an Arcam receiver...
One thing I would like to mention is that I had some difficulties setting up synchronator, one of the things that took me quite some time to resolve was a "no such file" issue when starting synchronator via ssh (as advised in the install manual). Obviously libconfig was not reachable. I resolved this (After a few hours) by doing ldconfig. I believe mentioning ldconfig in the install manual might save other people some trouble (at least for newbies like myself...)
Best Regards,
Lars
Am 07.04.2017 um 22:40 schrieb Schorsch:
Thanks for the quick fix! I can't try it tonight, but I'll definetely give it a go tomorrow. :-)
Am 7. April 2017 20:00:11 MESZ schrieb Muffinman notifications@github.com:
I've reproduced this issue and committed a fix. If this doesn't resolve your issue, please reopen this issue. https://github.com/therealmuffin/synchronator/tree/76c2f7286988b5a4a6661353be922fd2d64f7bc7 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/therealmuffin/synchronator/issues/5#issuecomment-292608524>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZxAX4jgFHGaCo4LI-YVvA2jLGr80_Ccks5rtnmrgaJpZM4M3DaJ>.
therealmuffin
commented
7 years ago Hello Lars,
Good to hear its working and thanks for your comment! I can't say I have heard the ldconfig issue before, for me exporting the LD_LIBRARY_PATH is sufficient. Is running 'ldconfig' without options sufficient to solve the issue? Are you running a Debian like system (incl. Ubuntu)?
Kind regards, Maarten
p.s. currently I'm implementing a feature so users can easily upload configuration file(s) so they can be added as a sample to the repository. For the time being, would you mind uploading yours to https://gist.github.com/ (or otherwise) and sending me the link?
On 12/04/2017 01:41, Schorsch99 wrote:
Hi,
everything working fine now, thanks!
Seems like I was the first one to use the program with an Arcam receiver...
One thing I would like to mention is that I had some difficulties setting up synchronator, one of the things that took me quite some time to resolve was a "no such file" issue when starting synchronator via ssh (as advised in the install manual). Obviously libconfig was not reachable. I resolved this (After a few hours) by doing ldconfig. I believe mentioning ldconfig in the install manual might save other people some trouble (at least for newbies like myself...)
Best Regards,
Lars
Am 07.04.2017 um 22:40 schrieb Schorsch:
Thanks for the quick fix! I can't try it tonight, but I'll definetely give it a go tomorrow. :-)
Am 7. April 2017 20:00:11 MESZ schrieb Muffinman notifications@github.com:
I've reproduced this issue and committed a fix. If this doesn't resolve your issue, please reopen this issue.
https://github.com/therealmuffin/synchronator/tree/76c2f7286988b5a4a6661353be922fd2d64f7bc7
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub
https://github.com/therealmuffin/synchronator/issues/5#issuecomment-292608524, or mute the thread
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/therealmuffin/synchronator/issues/5#issuecomment-293431320, or mute the thread https://github.com/notifications/unsubscribe-auth/AArbqgZ1Pa_UhURtg7F9fmMPTWaMdBnqks5rvA-mgaJpZM4M3DaJ.
Schorsch99
commented
7 years ago Hello Maarten,
yes, ldconfig without options was sufficient. I am running OSMC (Debian based) on a Raspberry Pi 2.
As I am not really a Linux-crack (actually a Newbie, at least WRT command line...) the entire setup cost me quite some time, especially since I never really knew WHY it was not working.
At one point it was permissions, then the issue with the libconfig not found, and then the TCP/IP thing which had me puzzled for some time until I dug out wireshark. Once identified, you thankfully resolved it very quickly :-) A routinized Linux "nerd" probably would have had everything set up in 5 minutes and quickly identified the bug...
One other thing you may want to change to make life easier for newbies like me:
In the install manual you mention:
"Copy the configuration file to the directory /usr/local/etc/ or /etc/ with the name synchronator.conf:"
I copied it to /etc/ but it did not work. Took me some time to find out that in this case DAEMON_ARGS in /etc/init.d/synchronator needs to be changed accordingly, because otherwise it passes along the wrong config-file-path to synchronator...
Regarding the conf file: I'll give it a try... I'm new to github, in fact I only signed up to get in contact with you because of the port-number-bug...
I pimped the conf-file with some comments and copied it to
https://gist.github.com/anonymous/3df5eb3437383f79000eb116b0a08933
I hope that is the right link.
By the way, I tested with this setup:
AV-receiver: ARCAM AVR390 (tested with RS232 via USB to RS232 adapter as well as TCP/IP)
Renderer: Raspberry Pi2 running OSMC, mpd, upmpdcli, synchronator (currently only using synchronator for mpd/upmpdcli, not for KODI)
Server: MinimServer / BubbleUPNP server on Synology NASCan you tell me what needs to be changed to use synchronator also for KODI?
Thanks and Best Regards,
Lars
Am 12.04.2017 um 19:29 schrieb Muffinman:
Hello Lars,
Good to hear its working and thanks for your comment! I can't say I have heard the ldconfig issue before, for me exporting the LD_LIBRARY_PATH is sufficient. Is running 'ldconfig' without options sufficient to solve the issue? Are you running a Debian like system (incl. Ubuntu)?
Kind regards, Maarten
p.s. currently I'm implementing a feature so users can easily upload configuration file(s) so they can be added as a sample to the repository. For the time being, would you mind uploading yours to https://gist.github.com/ (or otherwise) and sending me the link?
On 12/04/2017 01:41, Schorsch99 wrote:
Hi,
everything working fine now, thanks!
Seems like I was the first one to use the program with an Arcam receiver...
One thing I would like to mention is that I had some difficulties setting up synchronator, one of the things that took me quite some time to resolve was a "no such file" issue when starting synchronator via ssh (as advised in the install manual). Obviously libconfig was not reachable. I resolved this (After a few hours) by doing ldconfig. I believe mentioning ldconfig in the install manual might save other people some trouble (at least for newbies like myself...)
Best Regards,
Lars
Am 07.04.2017 um 22:40 schrieb Schorsch:
Thanks for the quick fix! I can't try it tonight, but I'll definetely give it a go tomorrow. :-)
Am 7. April 2017 20:00:11 MESZ schrieb Muffinman notifications@github.com:
I've reproduced this issue and committed a fix. If this doesn't resolve your issue, please reopen this issue.
https://github.com/therealmuffin/synchronator/tree/76c2f7286988b5a4a6661353be922fd2d64f7bc7
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub
https://github.com/therealmuffin/synchronator/issues/5#issuecomment-292608524,
or mute the thread
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub
https://github.com/therealmuffin/synchronator/issues/5#issuecomment-293431320, or mute the thread
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/therealmuffin/synchronator/issues/5#issuecomment-293650865, or mute the thread https://github.com/notifications/unsubscribe-auth/AZxAX3wV7YvOObKaVecHtWTsyb9HEDTvks5rvQoCgaJpZM4M3DaJ.
Schorsch99
commented
7 years ago Hello Maarten,
I guess I was just too tired last night (it was 3 in the morning when I sent the mail) so that I forgot to really say "thanks!" :-) This little addition was just what I was looking for!
Have a great day!
Best Regards,
Lars
P.S. Please let me know if you can access the conf-file on github or if I should send it by mail
therealmuffin
commented
7 years ago Hallo Lars,
Glad you find it useful. When writing Synchronator for my equipment I figured I couldn't be the only one annoyed by needing two remotes!
Anyways, thanks for your feedback, config file and persistence in figuring out this particular bug. I've modified the install manual based on your feedback.
In addition, I've increased the flexibility of Synchronator a bit. Now you can also control power and other options for your amp (and similar). I hope that source control also works but I couldn't get clarity in the Arcam manual on that (though it would be quite silly if it didn't work). Anyways, you can use these options via trigger scripts of which a few examples are included in the folder scripts. If you're interested in this functionality and do try it out I would appreciate feedback of whether it works as intended.
As for Kodi, I'll dig up my notes and create a sort of manual. Preferably I would have it be a standard option in Kodi, but the folks over there didn't seem to care or convinced of the usefulness. If that changes I wouldn't mind creating a proper patch.
Kind regards, Maarten
On 13/04/2017 09:44, Schorsch99 wrote:
Hello Maarten,
I guess I was just too tired last night (it was 3 in the morning when I sent the mail) so that I forgot to really say "thanks!" :-) This little addition was just what I was looking for!
Have a great day!
Best Regards,
Lars
P.S. Please let me know if you can access the conf-file on github or if I should send it by mail
Hello Maarten,
yes, ldconfig without options was sufficient. I am running OSMC (Debian based) on a Raspberry Pi 2.
As I am not really a Linux-crack (actually a Newbie, at least WRT command line...) the entire setup cost me quite some time, especially since I never really knew WHY it was not working.
At one point it was permissions, then the issue with the libconfig not found, and then the TCP/IP thing which had me puzzled for some time until I dug out wireshark. Once identified, you thankfully resolved it very quickly :-) A routinized Linux "nerd" probably would have had everything set up in 5 minutes and quickly identified the bug...
One other thing you may want to change to make life easier for newbies like me:
In the install manual you mention:
"Copy the configuration file to the directory /usr/local/etc/ or /etc/ with the name synchronator.conf:"
I copied it to /etc/ but it did not work. Took me some time to find out that in this case DAEMON_ARGS in /etc/init.d/synchronator needs to be changed accordingly, because otherwise it passes along the wrong config-file-path to synchronator...
Regarding the conf file: I'll give it a try... I'm new to github, in fact I only signed up to get in contact with you because of the port-number-bug...
I pimped the conf-file with some comments and copied it to
https://gist.github.com/anonymous/3df5eb3437383f79000eb116b0a08933
I hope that is the right link.
By the way, I tested with this setup:
AV-receiver: ARCAM AVR390 (tested with RS232 via USB to RS232adapter as well as TCP/IP)
Renderer: Raspberry Pi2 running OSMC, mpd, upmpdcli,synchronator (currently only using synchronator for mpd/upmpdcli, not for KODI)
Server: MinimServer / BubbleUPNP server on Synology NASCan you tell me what needs to be changed to use synchronator also for KODI?
Thanks and Best Regards,
Lars
Am 12.04.2017 um 19:29 schrieb Muffinman:
Hello Lars,
Good to hear its working and thanks for your comment! I can't say I have heard the ldconfig issue before, for me exporting the LD_LIBRARY_PATH is sufficient. Is running 'ldconfig' without options sufficient to solve the issue? Are you running a Debian like system (incl. Ubuntu)?
Kind regards, Maarten
p.s. currently I'm implementing a feature so users can easily upload configuration file(s) so they can be added as a sample to the repository. For the time being, would you mind uploading yours to https://gist.github.com/ (or otherwise) and sending me the link?
On 12/04/2017 01:41, Schorsch99 wrote:
Hi,
everything working fine now, thanks!
Seems like I was the first one to use the program with an Arcam receiver...
One thing I would like to mention is that I had some difficulties setting up synchronator, one of the things that took me quite some time to resolve was a "no such file" issue when starting synchronator via ssh (as advised in the install manual). Obviously libconfig was not reachable. I resolved this (After a few hours) by doing ldconfig. I believe mentioning ldconfig in the install manual might save other people some trouble (at least for newbies like myself...)
Best Regards,
Lars
Am 07.04.2017 um 22:40 schrieb Schorsch:
Thanks for the quick fix! I can't try it tonight, but I'll definetely give it a go tomorrow. :-)
Am 7. April 2017 20:00:11 MESZ schrieb Muffinman notifications@github.com:
I've reproduced this issue and committed a fix. If this doesn't resolve your issue, please reopen this issue.
https://github.com/therealmuffin/synchronator/tree/76c2f7286988b5a4a6661353be922fd2d64f7bc7
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub
https://github.com/therealmuffin/synchronator/issues/5#issuecomment-292608524,
or mute the thread
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub
https://github.com/therealmuffin/synchronator/issues/5#issuecomment-293431320, or mute the thread
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/therealmuffin/synchronator/issues/5#issuecomment-293817232, or mute the thread https://github.com/notifications/unsubscribe-auth/AArbqvIXeMXnWKv9UjNSjaNRzOR_3L28ks5rvdJCgaJpZM4M3DaJ.
Schorsch99
commented
7 years ago Hello Marteen,
sorry for the very late reply... While fiddling around with the Raspi I neglected some other "fun" stuff that I had to catch up on, like completing my tax declaration, replacing a toilet bowl (great fun...) and repairing several things around the house :-(
I will try out the trigger scripts as soon as I get around to it, interesting stuff!
I did find the time (at night :-) to do a fresh install of Raspbian Lite, (updated to Kernel 4.9) on which I installed mpd, upmpdcli and synchronator. I tried to follow the instructions to the letter and found one more item in the install manual that did not work for me as indicated in the manual:
When I get to this point:
Testing the setup
It's time to test the setup. Run the following:
synchronator -v2
this does not work. I don't know the exact error message (I have it at home, I'm in the office now), but I can provide that later, if needed.
If I skip this step and continue with the rest of the manual, it works nevertheless. So it is just this intermediate test that is not working at this point.
Synchronator is now basically working (TCP communication and all), but not very well. Let me explain:
The volume control at the controlpoint is sort of "sticky" and "jumpy" (for the lack of better words) and the numeric display on the control point does not match the Arcam's display. I have checked with synchronator in verbose that the ARCAM sends the correct volume level, meaning that the volume info on the ARCAM display and ones received by synchronator match (i.e. 32 on display, 32 reported by Debug message)
Also the volume indicator at the controlpoint and the level indicated in alsamixer match 1:1 (0=0, 10=10, 100=100, etc) and follow each other smoothly (bidirectional)
But the volume indicator at the controlpoint does never match the ARCAM (except at "0"). See attached a screenshot of the discrepancies (can also send as excel, if needed).
target: the level I am trying to set at the controlpoint
Controlpoint: the value it reverts to
AV-Receiver: the volume level set at the receiver
Highlighted in yellow are values that can not be set at the control point: e.g. whenever I try to set 50, the controlpoint reverts to 51 after approx. 1 s (after receiving response from receiver?).
Now this happens on the freshly installed Raspbian with your version including the flexible position command code, whereas on my old installation (OSMC) with your previous version (no flexible command code position, but with the TCP-fix) everything works fine. I don't know if that info is of any significance.
To me it appears as if synchronator is applying a logarithmic curve, but only unidirectionally, so that real synchronization fails and results in the jumpy response.
Can you point me in the right direction? Is there any parameter that I may have accidentally added/omitted?
If I can support with some debug messages, let me know.
Thanks again!
Best Regards,
Lars
therealmuffin
commented
7 years ago Hello Lars,
Thanks for your observation on the 'synchronator -v2' issue. Indeed, if you follow the extended manual, that won't work. I've pushed a fix that solves that.
As for your volume control issue. Synchronator by default does not apply a logarithmic scale (though the option exists). The input volume levels are translated in a linear fashion to the output device. The output range may be reduced to prevent damaging the speakers due too high volume levels, however, that has no effect on the control point or renderer. Whatever the settings, the back and forth translations are always near identical (some rounding difference might occur when using the logarithmic scale). For more info, see the volume section in the config manual
Alsamixer, on the other hand, is not linear. But that's not relevant since alsamixer is not a source for Synchronator. However, it does suggest that either your control client or renderer isn't linear (most likely the latter)?
Besides a strange volume curve, it shouldn't cause jumps in the volume level.
To check if this issue is specific to the recent Synchronator update: after the git clone command, cd to the synchronator location and execute the following command: git reset --hard 76c2f7286988b5a4a6661353be922fd2d64f7bc7
Do not forget to use the older config file since they differ between both versions.
This should bring you back to the tcp port fix. If the issue is gone I'll have to do some testing.
Kind regards, Maarten
Schorsch99
commented
7 years ago Hello Marteen, I'll give your suggestion a try and get back to you. I doubt that the issue is the renderer though, because it works fine on my OSMC installation, and that includes the same version of mpd and upmpcli on the identical hardware. Anyway, thanks again and I will keep you posted. :-) Best regards, Lars
Am 26. April 2017 18:43:51 MESZ schrieb Muffinman notifications@github.com:
Hello Lars,
Thanks for your observation on the 'synchronator -v2' issue. Indeed, if you follow the extended manual, that won't work. I've pushed a fix that solves that.
As for your volume control issue. Synchronator by default does not apply a logarithmic scale (though the option exists). The input volume levels are translated in a linear fashion to the output device. The output range may be reduced to prevent damaging the speakers due too high volume levels, however, that has no effect on the control point or renderer. Whatever the settings, the back and forth translations are always near identical (some rounding difference might occur when using the logarithmic scale). For more info, see the volume section in the config manual
Alsamixer, on the other hand, is not linear. But that's not relevant since alsamixer is not a source for Synchronator. However, it does suggest that either your control client or renderer isn't linear (most likely the latter)?
Besides a strange volume curve, it shouldn't cause jumps in the volume level.
To check if this issue is specific to the recent Synchronator update: after the git clone command, cd to the synchronator location and execute the following command: git reset --hard 76c2f7286988b5a4a6661353be922fd2d64f7bc7
This should bring you back to the tcp port fix. If the issue is gone I'll have to do some testing.
Kind regards, Maarten
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/therealmuffin/synchronator/issues/5#issuecomment-297471121
Schorsch99
commented
7 years ago Hello Marteen,
I have a stupid question to help me troubleshoot.
In verbose, I get e.g. the following when changing volume on the controlpoint:
synchronator[936]: Volume level mutation (int. initiated): ext. level: 34.65
synchronator[936]: Incoming volume level processing timeout (completed): 0/2
synchronator[936]: Leftovers in buffer (bytes read, #leftovers): ! (7, 0)
is "ext. level" the value SENT to the Receiver, or is it what the receiver REPLIES? In this case both controlpoint and alsamixer show "18", the Receiver shows 34.
If this is what the Receiver replies, is there any way I can get Debug to show what is SENT?
Thanks for your patience!
Best Regards,
Lars
Am 26.04.2017 um 18:54 schrieb Schorsch:
Hello Marteen, I'll give your suggestion a try and get back to you. I doubt that the issue is the renderer though, because it works fine on my OSMC installation, and that includes the same version of mpd and upmpcli on the identical hardware. Anyway, thanks again and I will keep you posted. :-) Best regards, Lars
Am 26. April 2017 18:43:51 MESZ schrieb Muffinman notifications@github.com:
Hello Lars, Thanks for your observation on the 'synchronator -v2' issue. Indeed, if you follow the extended manual, that won't work. I've pushed a fix that solves that. As for your volume control issue. Synchronator by default does not apply a logarithmic scale (though the option exists). The input volume levels are translated in a linear fashion to the output device. The output range may be reduced to prevent damaging the speakers due too high volume levels, however, that has no effect on the control point or renderer. Whatever the settings, the back and forth translations are always near identical (some rounding difference might occur when using the logarithmic scale). For more info, see the volume section in the config manual <https://github.com/therealmuffin/synchronator/tree/master/CONFIG_MANUAL.md> Alsamixer, on the other hand, is not linear. But that's not relevant since alsamixer is not a source for Synchronator. However, it does suggest that either your control client or renderer isn't linear (most likely the latter)? Besides a strange volume curve, it shouldn't cause jumps in the volume level. To check if this issue is specific to the recent Synchronator update: after the git clone command, cd to the synchronator location and execute the following command: git reset --hard 76c2f72 <https://github.com/therealmuffin/synchronator/commit/76c2f7286988b5a4a6661353be922fd2d64f7bc7> This should bring you back to the tcp port fix. If the issue is gone I'll have to do some testing. Kind regards, Maarten — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/therealmuffin/synchronator/issues/5#issuecomment-297471121>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZxAX7pZmpq0VlgTrOsvvz_XbBZ57JF3ks5rz3RHgaJpZM4M3DaJ>.
Schorsch99
commented
7 years ago Sorry, here's a better trace:
Apr 26 19:41:53 raspberrypi synchronator[936]: Volume level mutation (int. initiated): ext. level: 34.65 Apr 26 19:41:53 raspberrypi synchronator[936]: Incoming volume level processing timeout (completed): 1/2 Apr 26 19:41:53 raspberrypi synchronator[936]: Leftovers in buffer (bytes read, #leftovers): !#001#015 (7, 0)
Am 26.04.2017 um 19:38 schrieb erdbeerschorsch:
Hello Marteen,
I have a stupid question to help me troubleshoot.
In verbose, I get e.g. the following when changing volume on the controlpoint:
synchronator[936]: Volume level mutation (int. initiated): ext. level: 34.65
synchronator[936]: Incoming volume level processing timeout (completed): 0/2
synchronator[936]: Leftovers in buffer (bytes read, #leftovers): ! (7, 0)
is "ext. level" the value SENT to the Receiver, or is it what the receiver REPLIES? In this case both controlpoint and alsamixer show "18", the Receiver shows 34.
If this is what the Receiver replies, is there any way I can get Debug to show what is SENT?
Thanks for your patience!
Best Regards,
Lars
Am 26.04.2017 um 18:54 schrieb Schorsch:
Hello Marteen, I'll give your suggestion a try and get back to you. I doubt that the issue is the renderer though, because it works fine on my OSMC installation, and that includes the same version of mpd and upmpcli on the identical hardware. Anyway, thanks again and I will keep you posted. :-) Best regards, Lars
Am 26. April 2017 18:43:51 MESZ schrieb Muffinman notifications@github.com:
Hello Lars, Thanks for your observation on the 'synchronator -v2' issue. Indeed, if you follow the extended manual, that won't work. I've pushed a fix that solves that. As for your volume control issue. Synchronator by default does not apply a logarithmic scale (though the option exists). The input volume levels are translated in a linear fashion to the output device. The output range may be reduced to prevent damaging the speakers due too high volume levels, however, that has no effect on the control point or renderer. Whatever the settings, the back and forth translations are always near identical (some rounding difference might occur when using the logarithmic scale). For more info, see the volume section in the config manual <https://github.com/therealmuffin/synchronator/tree/master/CONFIG_MANUAL.md> Alsamixer, on the other hand, is not linear. But that's not relevant since alsamixer is not a source for Synchronator. However, it does suggest that either your control client or renderer isn't linear (most likely the latter)? Besides a strange volume curve, it shouldn't cause jumps in the volume level. To check if this issue is specific to the recent Synchronator update: after the git clone command, cd to the synchronator location and execute the following command: git reset --hard 76c2f72 <https://github.com/therealmuffin/synchronator/commit/76c2f7286988b5a4a6661353be922fd2d64f7bc7> This should bring you back to the tcp port fix. If the issue is gone I'll have to do some testing. Kind regards, Maarten — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/therealmuffin/synchronator/issues/5#issuecomment-297471121>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZxAX7pZmpq0VlgTrOsvvz_XbBZ57JF3ks5rz3RHgaJpZM4M3DaJ>.
therealmuffin
commented
7 years ago Hello Lars,
The external level refers to the volume level external to the computer, thus your amplifier. It is internally initiated, thus this is the level send to the amplifier. Since your amp accepts only integers, the digits after the dot are ignored.
Since the outgoing data is in decimal format rather than ascii, providing that data in a readible format increases the footprint of Synchronator too much for my liking. However, the reported volume level is logged right before it is send, so I'm confident it is the actual volume level used. If the amp's volume level changes in response to that command, than the formatting of the command is also correct. Do note, volume ranges do not always correspond between what's on the display and what it uses in the backend.
Kind regards, Maarten
Schorsch99
commented
7 years ago Hello Marteen,
no progress yet, as I havn't gotten around to testing.
One thing I noticed in the configuration manual in this section:
Main section settings
Parameters that could differ between incoming and outgoing commands are defined between parentheses (regardless of wether diff_commands is TRUE or not). If incoming and outgoing parameters differ, the incoming version is defined first, followed by a comma and then the outgoing version.
header - prefix to every command
event_delimiter - delimiter between command code and its parameter
tail - suffix to every command
Maybe it is my misinterpretation, but if you define "outgoing" as "sent from synchronator to AMP", then the sequence in the conf-file is the other way around, isn't it? (Outgoing first, followed by comma, then incoming)
Best Regards,
Lars
Gesendet: Mittwoch, 26. April 2017 um 20:56 Uhr Von: Muffinman notifications@github.com An: therealmuffin/synchronator synchronator@noreply.github.com Cc: Schorsch99 mumpitz99@nurfuerspam.de, Author author@noreply.github.com Betreff: Re: [therealmuffin/synchronator] IP-Control - 5-digit port numbers are truncated (#5)
Hello Lars,
The external level refers to the volume level external to the computer, thus your amplifier. It is internally initiated, thus this is the level send to the amplifier. Since your amp accepts only integers, the digits after the dot are ignored.
Since the outgoing data is in decimal format rather than ascii, providing that data in a readible format increases the footprint of Synchronator too much for my liking. However, the reported volume level is logged right before it is send, so I'm confident it is the actual volume level used. If the amp's volume level changes in response to that command, than the formatting of the command is also correct. Do note, volume ranges do not always correspond between what's on the display and what it uses in the backend.
Kind regards, Maarten
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
therealmuffin
commented
7 years ago Hallo Lars,
Thanks for noticing, fixed the mixup.
Kind regards, Maarten
Schorsch99
commented
7 years ago Hello Marteen,
glad to be of help!
BTW: I found the cause of the strange behaviour in my new installation a few minutes ago:
After unsuccessfully fiddling around with all kinds of stuff, among others installing the "old" version of synchronator as you suggested, I finally found the culprit... and you were right! It actually was the renderer.
I noticed that the working OSMC setup had an older version of mpd installed (0.19.1-1.1) whereas the "malfunctioning" raspbian setup had mpd 0.20.6.
I downgraded the mpd package and everything works fine now. Display on controlpoint and Receiver are now a 1:1 match. (even more so after I changed the max. volume in conf-file from 99 to 100 to avoid rounding errors).
Now I'm off to bed... Have a good day!
Best Regards,
Lars
Am 27.04.2017 um 17:45 schrieb Muffinman:
Hallo Lars,
Thanks for noticing, fixed the mixup.
Kind regards, Maarten
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/therealmuffin/synchronator/issues/5#issuecomment-297754264, or mute the thread https://github.com/notifications/unsubscribe-auth/AZxAX1m5U0e0LYL1Vu7sF1VDAhaJKjZxks5r0LgugaJpZM4M3DaJ.
Schorsch99
commented
7 years ago Hello Marteen,
here's a quick follow-up which may be interesting for you. The issue with the strange display/volume control will potentially affect others when using mpd versions 0.20.1 and newer. There appears to be a change in the mpd-behaviour beginning with 0.20.1, here is an extract from the changelog:
...
ver 0.20.1 (2017/01/09)
...
I found the relevant section in the sources on github under
MPD/src/mixer/plugins/volume_mapping.c
I think these volume translations collide with Synchronator and produce these strange effects.
I haven't found any way to disable this new feature in the mpd.conf (yet). If you happen to stumble onto something please let me know.
Best Regards,
Lars
Hello Marteen,
glad to be of help!
BTW: I found the cause of the strange behaviour in my new installation a few minutes ago:
After unsuccessfully fiddling around with all kinds of stuff, among others installing the "old" version of synchronator as you suggested, I finally found the culprit... and you were right! It actually was the renderer.
I noticed that the working OSMC setup had an older version of mpd installed (0.19.1-1.1) whereas the "malfunctioning" raspbian setup had mpd 0.20.6.
I downgraded the mpd package and everything works fine now. Display on controlpoint and Receiver are now a 1:1 match. (even more so after I changed the max. volume in conf-file from 99 to 100 to avoid rounding errors).
Now I'm off to bed... Have a good day!
Best Regards,
Lars
Am 27.04.2017 um 17:45 schrieb Muffinman:
Hallo Lars,
Thanks for noticing, fixed the mixup.
Kind regards, Maarten
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
therealmuffin
commented
7 years ago Hello Lars,
Thanks for investigating this issue. If you like you can create a new issue for this. This is something that needs a fix or work around. I'll check if something can be changed on the MPD end and otherwise I'll have to think of something else.
Kind regards, Maarten
When using IP-control, the last digit of 5-digit port numbers is truncated, 4 digits and lower are OK:
A (more or less) functioning workaround is remapping from 5000 to 50000 with iptables.