Re: [SlimDevices: Unix] Memory Leak in Perl Engine on piCorePlayer?

Sun, 21 Mar 2021 15:36:09 -0700 


I am not sure about all the debugging stuff, but it appears to me that
it is not a matter of configuring things but of changing the code. I
have tried to increase the amount of logging for a few items but didn't
learn much. Where is all the code? The directory containing the
slimserver.pl only contains 9 pl files in total, and only gdresize.pl
uses File::Temp.
Code:
--------------------
    tc@piCoreServer:/tmp/tcloop/slimserver/usr/local/slimserver$ find . -name 
"*.pl" -print
  ./CPAN/AnyEvent/Util/idna.pl
  ./CPAN/AnyEvent/Util/uts46data.pl
  ./CPAN/AnyEvent/constants.pl
  ./CPAN/XML/SAX/placeholder.pl
  ./cleanup.pl
  ./gdresize.pl
  ./gdresized.pl
  ./scanner.pl
  ./slimserver.pl
--------------------
But I used the opportunity to update the LMS and watch a fresh system
playing an album from Tidal. I now understood why just counting the
number of open file handles does not help with understanding what is
happening. Every track creates and destroys two sockets and two pipes,
and there are other activities adding to the noise, like the caching of
album art. But when it comes to temporary files, the behaviour is rather
straightforward.

Every single track played leaves a temporary file behind with an open
file handle in slimserver.pl. The files are rather uniform. They seem to
contain mp4 metadata. I downloaded one of the mp4 tracks, too, and it
looks nothing like those temporary files, although with binary data,
this is hard to say. All temporary files start with binary data and end
like this:
Code:
--------------------
    udta�meta-hdlrmdirilst 
handlerilstr----(meanorg.hydrogenaudio.replaygain&namereplaygain_originator_codedata011011000000i----(meanorg.hydrogenaudio.replaygain!namereplaygain_track_gaindata-7.87
 dBi----(meanorg.hydrogenauIuuidDLBY-METADATA-00�meta3hdlrdlbtdolby 
tags handler&#65533;xml<?xml version="1.0" encoding="UTF-8"?>
  <protected xmlns="http://www.dolby.com/ns/mobile/protected-1.0";>
  <payload>
  <tags xmlns="http://www.dolby.com/ns/mobile/tags-1.0"; 
id="febbcb871e10fe78fcb42572d432c797" read-only="true">
  <tag name="tool-info" lang="und">
  
<data>LS1pbnB1dC1maWxlIDxhcmc+IC0tb3V0cHV0LWZpbGUgPGFyZz4gLS1hdWRpby1lbmNvZGVyIGFhYyAtLWF1ZGlvLWNici1yYXRlIDMyMCAtLWFhYy1tb2RlIGFhYyAtLWlucHV0LXNwZWVjaCBmYWxzZSAtLWF1ZGlvLW9ubHkgLS1yZXBsYXlnYWluIG9uIC0tYXVkaW8tcHJvcC1tZXRhIGxvdWRuZXNzIA==</data>
  </tag>
  </tags>
  </payload>
  <signature algorithm="hmac-md5">a8d5be608e4aca0266c159418d806a4e</signature>
  </protected>
  &#65533;meta;hdlrdlbfdolby file metrics handlerqxml <?xml version="1.0" 
encoding="UTF-8"?>
  <protected xmlns="http://www.dolby.com/ns/mobile/protected-1.0";>
  <payload>
  <file-metrics xmlns="http://www.dolby.com/ns/mobile/file-metrics-1.0"; 
id="febbcb871e10fe78fcb42572d432c797">
  <dolby-app-version>Dolby Media Generator 3.8.3</dolby-app-version>
  <creation-date>2016-08-12T17:57:06</creation-date>
  <creation-id>115124</creation-id>
  <stream id="1" type="audio">
  <encoder-description>Dolby Pulse Encoder 1.1.4 sbr: 4.0 / Aug 18 
2011</encoder-description>
  <encoder>AAC</encoder>
  <bitrate-mode>VBR</bitrate-mode>
  <bitrate>320000</bitrate>
  <duration unit="frames">9765888</duration>
  <signature algorithm="md5">1c5f05da944468156c140c483176ed9d</signature>
  <audio-info>
  <samplerate>44100</samplerate>
  <channel-count>2</channel-count>
  <encode-mode>None</encode-mode>
  <encode-delay>1600</encode-delay>
  </audio-info>
  </stream>
  </file-metrics>
  </payload>
  <signature algorithm="hmac-md5">0f2340c558a9c8d72d0ce1fadcd2ff28</signature>
  </protected>
  mmeta;hdlrdlbkdolby audio kernel handler&xml <?xml version="1.0" 
encoding="UTF-8"?>
  <protected xmlns="http://www.dolby.com/ns/mobile/protected-1.0";>
  <payload>
  <audio-kernel xmlns="http://www.dolby.com/ns/mobile/audio-kernel-1.0"; 
id="febbcb871e10fe78fcb42572d432c797">
  <configuration>
  <config name="sample-rate" value="44100"/>
  </configuration>
  <parameters>
  <parameter name="tdas.reset" value="1"/>
  </parameters>
  </audio-kernel>
  </payload>
  <signature algorithm="hmac-md5">3c207014a46f955c7c617a330a9d1029</signature>
  </protected>
  3meta7hdlrdlbmdolby metadata handler&#65533;xml <?xml version="1.0" 
encoding="UTF-8"?>
  <protected xmlns="http://www.dolby.com/ns/mobile/protected-1.0";>
  <payload>
  <metadata xmlns="http://www.dolby.com/ns/mobile/metadata-1.0"; 
id="febbcb871e10fe78fcb42572d432c797">
  <replaygain stream-id="1">
  <parameter name="track-gain" value="-7.87 dB"/>
  <parameter name="track-peak" value="0.999969"/>
  <parameter name="originator-code" value="011011000000"/>
  </replaygain>
  <parameters stream-id="1">
  <parameter name="dialnorm" value="-10.13"/>
  <parameter name="peak-signal-amplitude" value="1.00"/>
  </parameters>
  </metadata>
  </payload>
  <signature algorithm="hmac-md5">36bbff96c50793db343f56cc653f0adb</signature>
  </protected>
  &#65533;)emdat
--------------------
The only time I saw one of the files being removed was when my playlist
contained only one track and I skipped forward, playing the same song
again. Skipping backward leaves the existing file in place, and so does
skipping forward to another track or the song ending on its own.



scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.2.0 | server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 & rmb-100 |
nubert nuvero 140
------------------------------------------------------------------------
mvordeme's Profile: http://forums.slimdevices.com/member.php?userid=22892
View this thread: http://forums.slimdevices.com/showthread.php?t=113321

_______________________________________________
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix

Reply via email to