Closed Sveninndh closed 9 months ago
Thanks! I slightly tweaked the PR to minimize the number of changes. Eg. we used to use my ($p) = @_
because it's supposed to be more efficient than the shift
. The latter would move things in memory, while the former only adds a pointer. Whether it really has an impact in our case I have my doubts đŸ˜€. But I kept it that way to not change that line.
Alles, klar, ich hatte mich Ă¼ber die Konstruktion my ($p) =@_; auch schon gewundert. my $p = shift; wirkt etwas einfacher. Ob das wirklich was im Speicher verschiebt kann sein muss aber nicht, könnte ja auch mit einem Pointer realisiert werden, Ich glaube auch eher nicht, dass es einen Unterschied macht.
Wieso sieht der letzte Merge Commit so aus?
[Merge commit 'd25362d982c69fffc50cc5303f28166692edccc4']
Was sieht da wie aus?
Merge commit 'd25362d982c69fffc50cc5303f28166692edccc4'
Ich meinte die Bezeichnung, was bedeutet diese HEX-Nummer, macht das GitHub automatisch?
Oh, das ist der "Commit Hash". Damit identifiziert Git eindeutig eine Änderung. Selbst wenn die nicht mehr in einem Branch oder so auftaucht, mit dem Hashwert ist die Änderung noch immer auffindbar. Eindeutig und unveränderlich.
There is an upper limit of 100 when displaying the Qobuz playlists. The changes fix the problem in that _pagingGet now evaluates the limit value that is supplied with the first _get() and then takes this as the new value for the page size. In addition, the playlists can only be read in completely if the paging mechanism is used. Otherwise, Qobuz stubbornly only delivers 100 entries as documented in the current source code.