gnump3d-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnump3d-users] Some improvements/changes/features


From: Michael
Subject: Re: [Gnump3d-users] Some improvements/changes/features
Date: Sat, 3 Dec 2005 16:10:45 +0800 (WST)

On Fri, 2 Dec 2005, Steve Kemp wrote:

On Fri, Dec 02, 2005 at 10:02:46PM +0800, Michael Collard wrote:

Done some work on the stable version of GNUMP3d that you may want to use
or add to. The attached diffs do the following:

 Great, thanks a lot.

 All the pathes look good except for this first one:

* Removed a space between #EXTINF: and the seconds count

 I don't have the mail to hand but I'm 99% positive that I used to
serve the file like that (i.e. without the space) and was then
sent a patch to add it in to make it more correct.

 So I'm going to leave this one out, unless you have a good
pointer to a document that suggests which is the correct behaviour.

I did check some other extended playlists created by other applications, they all had no spaces at the start of the fields. I didn't notice any problem when it was fed to XMMS anyways - so maybe its just superficial.

* Suggested a .m3u filename in the header for playlists so silly
  players like XMMS know whats coming

 Fine.

* Tag called $FULLPATH. Full path and filename for sorting etc

 Doesn't that disclose the local path to the music on the server?
 I can see a few people calling this a security issue, although
given that it must be enabled I see nothing wrong with it myself.

Nup, doesn't disclose the full path. However, I just realised that this is kind of redundant with the option to seperate the folders and files. I will remove this...

* Fixed bug with no paths put into @FOUND in &filesInDir

 Great.

* Case insensitive sorting on $FULLPATH and others

 :)

Well, I've spent some more time with some more bugs I've found. I've done the following:

* Directory variables now have trailing '/'
* random.pm, header from 300 to 302 for the redirection
* random.pm, leave tailing '/' on directories
* Proper skipping of dotfiles :)
* $FILENAME now includes relative path (for sorting)
* Trimming directories from FILENAME tag for display
* Trimming directories from random selections display for songs without tags

With all of these changes, Im not going to make a diff just yet for a couple of reasons. First because I will probably make more changes, and second, dunno what is happening with the below.

I am interested in people's opinion on if the recurs.m3u call should
result in files being selected that are NOT matching the viewing
preferences  (OGG, MP3 and Movies). Should they be selected or not?

 I think the viewing preferences are broken.  I think they
should be removed completely as this:

   a) simplifies the code.
   b) really came about from the bad old days when some players
      couldn't handle certain media files.

I think this is still an important option, but it needs to be implemented properly.

 I'd welcome user feedback though ..

IMO, the options should be changed so that the file types options
reflect what is viewed, and selected. This is just a personal
preference.

 I'd be happy to go with that if the concensus is that these
settings should persist.

Also, how bout custom playlists where not just directories can be
selected? Due to sheer volume of some directories, some thought would
need to be put in about how to go about this. But is this a feature
people want?

 My immediate thought there was "tagging", and extending the search
plugin to do things like:

   /search/song/foo

 To return all songs containing foo in their title, or
 /search/artist/Hendrix.

 I'm not 100% sure on how that would work though in terms of adding
the links intelligently.

 However I would suggest that any work on plugins should either
wait a few days, or only be done against the CVS repository since
the loading details have changed to be based upon this snippet:

   http://www.perlmonks.org/?node_id=120920

 Incomplete writeup:

   http://savannah.gnu.org/cgi-bin/viewcvs/gnump3d/gnump3d/PLUGINS


It should be good with the new plugin setup... allow many new things to be done. I'll finish up all the non plugin things that Im up to and then will make a unified diff for them




reply via email to

[Prev in Thread] Current Thread [Next in Thread]