Bugzilla – Bug 3175
Crash trying to browse real audio files
Last modified: 2008-09-15 14:38:25 UTC
The following information is part of the event: Not a SCALAR reference at /PerlApp/Slim/Web/HTTP.pm line 955. I was flailing around trying to see if I could get .rm files to play. I put some in a directory, then navigated there using Browse Music service. I then navigated to the folder with the .rm file, clicked on a file, then clicked on edit. The above crash resulted.
Marc - I'm not sure what you mean by "Clicked on Edit". Where in the web UI was this? The .rm files in my tree don't show in my Browse Music Folder at all. Does this still happen for you in the latest 6.2.2 nightly? Thanks.
clicked on edit...seems like this file was in the playlist folder. However, testing with the latest build, placing a .rm file in the music folder still allows it to be edited as if it were a playlist. Placing the file in the playlist folder, and clicking edit is fine. Placing it in music folder and click edit, the crash described above happens.
Where are you clicking on 'Edit' when it's in the Music Folder? I'm not even seeing the .rm file show up..
one possible quick fix, line 1521 of Slim/Web/Pages.pm changes to: if ($item->isPlaylist) { This adds the noEdit param to ALL playlists found in the music folder, so that we don't end up with the edit option and trigger the crash. Currently, this only adds noEdit to CUE sheets.
You have to have the AlienBBC plugin installed in order to have .rm recognised as a type. To test, I simply added the required line to types.conf (which alienBBC adds via Alien/custom-types.conf: rtsppl rm,ram,rpm,smil ? playlist Then, I placed the .rm file in the root of the music folder, and the root of the playlist folder. Rescan, or just navigate browse music folder. The playlist file should show up. Click on it, and you get the "browse playlist" page with the "rename, edit, delete" form at the top. Clicking on edit causes the crash. With the fix I mentioned above, it is just a listing (provided the rm points to valid files)
KDF - please check this in tonight after we've done 6.2.2
committed to trunk at change 7136. Holding off from stable branch until after official 6.2.2 or was it just for the FC1 tag?
Applied to the 6.3 branch as change 7149
This bug fix is now part of a released version, and so has been marked closed. If you are still experiencing this problem, please reopen the bug.