I was just wondering if there was any progress on a new version of the software.

Has anyone else have Win2K software that they are using?

1. No
2. The existing software works on Win2k

1. Ugh, i don't know which i want more now, empeg player 1.1 or a new 1.0x of the Reciever software. The big database bug is killing me. I've got too many mp3's.

2. I've got it running on win2k no problems.

||| loren |||

Receiver Software gets my vote. I am more than happy with Empeg at 1.03 ( when we get the radio ), however the Receiver software needs a few nips and tucks.

- --
Rod, UK Mk2 64gig Red S/No.341 Empeg 2 x DELL RioReceiver

loren,

How many is too many? I have 5,500 songs, taking up 22 GB of storage. How many/much do you have?

Good question, I am interested too. And also what happens when your database is too big ?

- --
Rod, UK Mk2 64gig Red S/N.341 Empeg 2xDigital Audio Receiver - one Wireless

Above about 18k songs, the server software goes bang during the database rebuild. Above about 7k songs, the player software goes bang trying to render the Select Music / Title menu. It should work if you use the search button instead, though.

It never indexes more than 250 tracks for a particular artist/genre/whatever.

For this, I apologise -- the database engine is custom (I wrote it), and it's missing some features. It does have other features that were important for the Receiver server, though.

In reply to:

---

Above about 18k songs, the server software goes bang during the database rebuild.

---

So will the receiver be usable if I point it at my 32,211 MP3s, or will I have to just use a subset? What are the plans for ironing out these limitations?

Nicholas.

--
Reproduction of this mail outside of this forum is prohibited.

You'll probably have to just use a subset -- try it and see. We're planning on replacing the backend-database with something a little more scalable.

The (current) plan is to ship the next version sat on top of a Microsoft Access database, but since it's probably gonna use ADO, it'll run on SQL server if you want to hack with it a little. The server running on my machine runs on SQL server with approx 25k MP3s in it.

The player still suffers from instability with a dataset that large -- it's the first thing on the list to get fixed when we get around to doing the next release.

The (current) plan is to ship the next version sat on top of a Microsoft Access database
Brrr, that gives me the shivers.
it'll run on SQL server if you want to hack with it a little
even more scarrier...

Have you guys ever though of an LDAP-backend? It's got a lot of usable features in the protocol, due to it's hierarchical access-methods.
- unlimited depth in playlist structure.
- unlimited database size through references to other servers
- integration with DNS (eg: give a player an ip-address & domain name with bootp/dhcp and it can find the rest itself )
- controlled access to other people's servers using ACL's which can allow/deny on IP/username/time of day/database query
- platform independant
- fast,stable and low on resources (well, openldap is. Netscape is another story)
and from a commercial viewpoint:
- have client-databases updated/synchronized with a central internet-server. Think of distributing LDAP-links to shoutcast, free/demo MP3 servers or ad-servers ( I can imagine coca-cola scrolling on the display ). It could even work sort as a TIVO...

If I can get some decent MP3 software to run on the receiver, I think I'm gonna try to write a simple player app. I'm just so used to the empeg's userinterface. After 1.03 for a while, I'm longing for wendy-filters...

I'm not saying MS-stuff is bad; I think both backends are each-others opposites. Access is designed for single-user access and SQLserver would seem overkill.


Frank van Gestel

I vote LDAP also, work with it quite a bit, however you can spend quite a lot of time working out how to make it perform well. I could also see that you would have to make install real simple. Many people appear to have a problem getting to grips with the concept and hence how to setup / admin LDAP.

- --
Rod, UK Mk2 64gig Red S/N.341 Empeg 2xDigital Audio Receiver - one Wireless

Double vote from me, not to have any MS backend - please stick to a OS independant solution. If there ever was a decision to move to Linux/Mac/whatever you be royally screwed.

Paul.

--
RioReceiver - Still Waiting for one in the UK.

In reply to:

---

I vote LDAP also, work with it quite a bit

---

OK, so I've been reading more and more about LDAP recently. I ought to give it a go, but I just can't find any decent documentation. Now, ideally I'd be after an O'Reilly book, but....

Does anybody have any suggestions?

Nicholas

--
Reproduction of this mail outside of this forum is prohibited.

look here for the specs and initial design of LDAP v1.
A search for LDAP at O'Reilly's site accounts for about 30 results, all about products built on or interfacing with LDAP, but not a special book about the protocol or server software. You actually shouldn't know about specific implementations, except when you are setting up one. All that should get you going is the protocol specification.

Frank van Gestel

We've already got a database API in there -- we've got an in-house version running against Berkeley-DB, so it's already MS-independent. At some point (once we've worked out the schema), we'll (Peter and myself, probably) code it up against MySQL.

The LDAP stuff sounds like a good idea. I don't, however, have any experience with it. Can you recommend:

a) a good book to read.
b) an implementation of it on Win32.

sorry i took so long to reply. Welp, as of yesterday i have 60+ gigs of mp3's. The server software does NOT like this, i can assure you. It renders the reciever pretty much useless for most of my collection.. i've had to use subsets as was suggested above, and can only index part of it all at once.

||| loren |||

Try OpenLDAP admin guide (online, or dowload the whole package). It includes decent intro, too.

Dragi "Bonzi" Raos

I don't really recommend LDAP. LDAP is just an access protocol, not a database technology. It would replace the http subset the receiver already uses, which isn't really all that useful as a step forward. The existing protocol is quite sufficient, and easily codable into a front end, regardless of the DB behind it. I worked on the LDAP interface to the Microsoft Win2K directory service, and as part of standards testing, also worked with Netscape and several others for interoperability testing and in ironing out the LDAP v2 spec. Bottom line is that any of the various implementations I worked on are only as good as the database underneath it.

I too have a private server. It uses an access database, and I reverse engineered the wire protocol. I use DAO against the database. I've only run it up to 3600 records. I've built user specifiable categorizations, so I have artist/album, or year/genre/composer, whatever. It's user speced, not hard coded into the DB.

LDAP is just an access protocol, not a database technology.

Gotcha, but Frank's mention of LDAP gave Hugo an idea for something else...

Oh, now that's cool. The only problem is that each DB has a different subset of SQL that is available. (My companies' prduct runs on SQLServer, Oracle, Sybase, Informix and DB2 UDB and OS/390).

I can tell you first hand that building such a thing is not easy.

Abstracting the data layer is a very good idea - but finding common SQL statements is very difficult - we ended up building different data layers for each database - so we get performant DB optimised SQL.

Cheers,

Paul.

--
RioReceiver - Still Waiting for one in the UK.

The only problem is that each DB has a different subset of SQL that is available.

Oh, that's easy. You just forget about outer joins, temporary tables, aggregate functions except count() and sum(), optimiser hints, nulls, stored procedures, recursive selects (God forbid), correlatad subqueries, isolation levels, locking strategy and timeouts, user-defined anything....

Seriously, such severely restricted interface can still usefull. See MySQL: no subqueries, no transactions (at the time of my last look), but still very usable as almost-readonly backend for, say, a web site.

Dragi "Bonzi" Raos

The only problem is that each DB has a different subset of SQL that is available.

I think the problem is that each DB has a different superset of SQL. SQL is the Cobol of data-access languages: its universality has given it a momentum out of all proportion to how well it actually solves the problem.

If anyone has any candidates for the ML, or even the C, of data-access languages, let me know. (Python plus a good DB abstraction, or C++ plus Microsoft's DB abstraction du jour might be close to the mark.)

Peter

a) a good book to read.
b) an implementation of it on Win32.


When I started exploring LDAP, about 5 years ago, there was no other usable documentation other than the umich ones and RFC's.
I started using LDAP to replace an access application which would read a dbfile from a network drive. The client for which I was working was using the netscape mailclient and had just placed a major order of 3000+ licences, about a month before netscape made a
"no license fee" policy.
Netscape's mailclient supports the LDAP-protocol(so does outlook), so I started investigating and installed umich's slapd on a HP 712/60 with 64Mb of memory(pizzabox). I would have to store about 3000 directory entries. So I did an access export to CSV, wrote a perl-script to convert the CSV to LDIF, and loaded the LDIF in slapd. Did some customizations to the mailclient to support other attributes and within a week I had a fully operational LDAP-server running, with respond-times in the msecs.
I was amazed. I rolled into my current workplace with a project to convert a company's "cgi-based shell scripts grepping on text files generated by an oracle dump" into an LDAP solution. I have had very good experiences with netscape server-software in the past, and I liked the administration of it through HTML-forms. They also provide a HTML->LDAP gateway, which is quite usable. I did the same trick as before, only there was a difference. It had to run on NT4, and systemmanagement was outsourced. The NT-admins thought it was a bad idea to install perl on it, so I decided to go for cygnus awk.
In the next half year, I was frequently called about a non-responsive system. It seemed the LDAP-server would no longer accept any new incoming connections. This would happen once every week. After a stop&start it was all OK again. After migrating to a sparc 250, I have had about a few hours of unscheduled downtime, at a running time of two year. We also got unix usermanagement as our responsibility, and my main plan was to implement it all in LDAP. Two years later, I've got a database which contains all human resources/nis users/nis groups/SMTP aliases/SMTP revaliases/DNS data/bootp data/lotus notes adresses/userquota/groupquota/IP network info; about 60000 records. The database is scanned for changes frequently through a changelog mechanism, using the LDAP protocol. When relevant changes occur, the data is read, formatted and distributed to various backends.
The version we currently use is 4.11. It's a shame the HTML admin-interface form 3.x is gone. They bundled a java app for administration, which, after several days of irritation, was uninstalled and forgotten about. I wrote my own win32 app for browsing directories. it's at http://www.sysman.nl/software/ldapper/index.html .
The HTML-interface is fine for basic record editing, but beware of problems using Internet Explorer and javascript. Major changes to the database(adding an IP-range) are mostly performed from commandline. There's also GQ, a linux directory browser/editor.
I like LDAP because of it's simplicity. Last week I spend about a day constructing an SQL-query to get some custom reporting from an SMS database, which resulted in a query which uses 10 inner joins, from which 5 of them rejoin the master table. phew...
In ldap I can just say :

ldapsearch surname=*gestel*

to give all people whose surname contains gestel

ldapsearch objectclass=ipnetwork netmask defaultgateway

gives a list of all networks,their subnetmasks and gateway address

ldapsearch (&(objectclass=bootpObject)(bootpTemplate=xterminal)) macaddress

gives a list of mac adresses of all xterminals
I also did some presentation on LDAP some time ago. Some of the slides are at http://empeg.dyndns.org/ldap

As for other servers, I just looked at http://verzeichnisdienst.de/ldap/Server/ and saw some interesting stuff : eudora and ibm both provide freeware LDAP-servers for NT/2000. Nescape can be quite expensive.
As for documentation, the books shipped with netscape directory server are very usable. I think they've got them online at http://developer.netscape.com

I'm must stop now, The children are at grandpa/ma and I am typing all this geeky stuff, when I could be drinking a trappist in the sun. I think I'll have to drag my wife from her computer. She's been chatting for 3 hours now...

Frank van Gestel

BTW, you could also install my LDAP-server for the empeg

Frank van Gestel

For what it's worth, and based on my experiences writing my own server, here's what I'd change in the system.

1) Move all the list processing to the server. Right now, when you open the "choose music" level, the choice of Artist/Album/Genre/Title/Playlist is hardcoded into the player. It should get the list of supported categories (really nothing more than top level playlists) from the server.

2) Move all shuffling to the server. The protocol lets the player request for shuffled return lists, but then shuffles the list again. Stop it, just let the server shuffle. This would let me do a feature where I can constrain the shuffle on the server. For example, I have a disc containing a couple of symphonies. I never want to break up the movements of the symphony, and they should always play in order. However, I would love to let the system shuffle which symphony is played first. This complex scenario could be handled with a decent admin on the server IF the client didn't reshuffle the list.

3) Make the schema data driven. Right now, the choice of which ID3 tags the system tracks is hardcoded into the server. I have a lot of classical music and make a lot of use of the composer, conductor, and orchestra ID3v2 tags. This single issue is what drove me to write my own server. I absolutely have to be able to look up music by composer. The admin tool for the server should let me specify which tags I want the system to manage, and should be extendable. This isn't all that hard, just store the schema in a separate table in the DB which is parsed first, and if someone extends the schema, create a new column in the data table in the DB.

4) Move the display templates to the server. OK, OK, they are actually there now (layout/en_UK/all_info, for example), but they are opaque. Publish the format of these things, or publish a tool that lets the user design them. Also, make sure this works with 3) above, so if I extend the schema to track composer, let me design a display template that puts the composer on the screen. This one I can't do yet in my own server, I haven't cracked the layout format, and I don't know if the layout code will work if I could somehow figure out how to tell it to display tag 0x10 (which in my system is the composer field).

5) Quit hardcoding which categorizations are supported. Let the user chose which categorizations he wants supported. My server lets the user build whatever categorizations he wants over whatever fields he wants. For example, the user can pick to categorize by artist, and he gets exactly the artist categorization already supported. He can also tell the server to maintain the categorization by artist then album. I support these categorizations as stored SQL queries (actually, just as the text of the select statements), not as explicit lists. As such, any column in the DB is as good as any other column for sorting.

6) This one you already know. The player should request info a couple of pages at a time. Then, it could easily handle lists of 100's of thousands of songs, since it would only need to store a little bit of local information.

7) Make the favorites list accessible as a playlist. This would let me walk up to a receiver, specify a few songs as favorites, then play the favorites list. Essentially, it let's me build a playlist without sitting down at my computer.

8) Build two parts for the server. The first part is the DB manager/web server/NFS server/DHCP server. It should run as a service or a normal app (mine just runs as a simple command line app, and I haven't yet turned it into a service. I also let my Win2k Server handle the DHCP stuff). The second part should be a graphical administration tool that talks to the server using the same protocol (suitably extended) as the receiver (the extensions I use are for things like sending in modification requests (i.e. change name, change composer, change...)). My server runs on my Win2k server machine, my admin runs on whatever machine in my network I happen to be sitting at.

Note that not all of these features are in my server yet, and it's not entirely stable, but in a few weeks, I intend to release an alpha/beta level of this for y'all to play with. My server also allows adding new songs without shutting down the DB, and monitors the music library for new tracks. Well, it rechecks every 6 hours, or whenever you use the admin tool to tell it to recheck for new tracks. In order to use my server, you will still need the software distributed with your receiver, I can't and won't redistribute any Empeg software.

The stupid edit text mode just fscked up all links in my post...
That's the second time. Is this a known bug?

Frank van Gestel

I could be drinking a trappist in the sun

Mmm, I was very, very impressed with the Westmalle triple trappist that I managed to haul back from the Amersfoort empeg meet -- and even more impressed when I found a small pub in Bath that sells the same stuff. Now all we need is one in *Cambridge*.

Peter

WOW.

That's an incredibly cool list of suggestions. I'm interested in hearing what the Empeg folks have to say about it.

Incidentally, your command-line app could probably be shoehorned into "SRVANY" on Windows NT/2K pretty easily.

___________
Tony Fabris

I've seen these BBS'es mess up embedded hypertext, but if you use the BBS markup language, it should be OK.

___________
Tony Fabris