When I edit the Schedule, my URLs (for the stream) is blank even though I saved it last time.
Interestingly, there seems to be some validation on the URL field because before I can save the schedule, I must input the URL. I used the URL that was working fine in the 5.x version of the station module and it saves fine.
However, when I click on the link on the "On Air" Block, I have a link that looks like http://www.mydomain.com/node/206/new.m3u.
When I click on that link, it simply reloads the schedule page. It does not open a page that loads a valid .m3u file.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | station_477724.patch | 8.71 KB | drewish |
Comments
Comment #1
drewish commentedyeah those are kinda broken still. i'd been meaning to do some work on those primarily to have them right out files so that they work without clean urls. could you give this patch a try and make sure it works for you?
Comment #2
drewish commentedmarked #477722: Edit Schedule produces SQL error Message as a duplicate.
Comment #3
cookiesunshinex commentedCheers for the quick turnaround. This worked!
I ran the patch on the files and uploaded them to the server.
After running update.php, I edited the schedule - I still got the sql error message.
However, when I input the correct URL and saved it, I saw a message stating that files/station directory was created and the schedule was properly saved.
Just for kicks I looked in the files/station directory and found a .m3u file.
I clicked on the On Air link and it properly loads like it did before in 5.x
A minor comment is that the file name created seems to be the node id plus the stream name in my case 206-Jungle_FM_128k_stream.m3u
Comment #4
drewish commentedgreat! the sql error is a result of crap being saved into the db. shouldn't be a problem going forward.
yeah i put the node id in there so it was easy to clean up the .m3u files if/when the node was deleted or updated. i suppose i could create a sub directory for each node if you think that would be better in terms of final filename...
Comment #5
cookiesunshinex commentedI think there are bigger fish to fry than this little issue.
I was thinking of it from a cleanliness perspective on if a user sees the downloaded .m3u file on the desktop or downloads folder at some point into the future.
I would say either close this or make it a low priority.
Comment #6
drewish commentedOkay, I'm going to go ahead and commit this now since as you point out there are more pressing issues.
By the way, that's a lot for the testing you've done. It's much more fun working on all this when there's immediate feedback. It's been a really big help.