Yet another in a series of blog posts meant to calm people down and explain just what is and isn’t going to be released “soon.” Don’t ask me when. When everybody else gets back from their vacations, we’ll vote on it.
In any event, I want to discuss the three favourite epithets people just love to fling at any kind of software whatsoever.
“Bloated” is the best one. People will accuse anything not written to live in a 64k .com file of being “bloated” — if they feel in an accusing mood. If there happens to be a feature a user doesn’t actually use, they get all upset about the extra megabyte of space taken on their 80-500GB hard drives.
We have about a 10MB download size. A third the size of someone else, twice the size of yet another. Does that mean we’re bloated?
Actually, we’re plenty “bloated.” That 10MB includes all sorts of XULRunner and VLC stuff that we probably don’t need but that I don’t want to hold up this release to sit down for a day and play trial and error with deleting things. Hell, right now we even include cygwin.dll because otherwise the custom vlc build we made gets all pissy about its memory allocations. Stupid, but we don’t want to spend the time on it yet.
The purpose of the core player is to provide a platform into which the user may choose to load all sorts of additional, external functionality. And to satisfy the public we will have to make the UI for that simple and easy.
So if we make the main binary package contain minimal functionality but still be full of big parts, are we bloated? Is 10MB either way on your HD really that big of a deal? That’s two whole mp3 files, for crying out loud.
And how about memory usage in a world where 1G sticks are ubiquitous?
XULRunner takes whatever XULRunner takes, and VLC takes whatever VLC takes, and SQLITE takes whatever SQLITE takes, and all the JS takes whatever the JS interpreter takes.
Doesn’t leave us much room for optimization. We make things worse by keeping a whole bunch of SQL indexes and result sets in ram to speed things up. We can probably tighten that up somewhat, eventually, but the livid truth is simply that if you have tons of tracks with tons of metadata, it’s going to take up tons of RAM. And the more track information we keep around to provide more functionality, the more RAM it takes. Welcome to Media Players 101.
Does that mean we’re bloated or not?
Do you really think you should care any more than whether or not it will fit and run on your machine?
Well, then, let’s talk about speed. One of the big things that people complain about winamp is the custom database code driving its library is slow. We’re using SQLITE instead and, as far as we can tell, it seems just fine on huge libraries. A second of pause on 6000 tracks with metadata seems acceptable to me.
But, as anyone can tell you, it’s slow as molasses inserting and updating a heavily indexed table.
Our APIs operate on database tables, often copying a number of rows from one table to another. Right now, most of these copies lock the UI out while they operate. We know that’s a big issue, and we’re working toward code to allow us to run batched database operations like these looped through the UI so it won’t block.
But retrofitting all of our API usage and then debugging the resulting mess would take longer than, again, we want to wait before we release code. So some functionality will, quite annoyingly we know, block the UI for a few seconds. Until we get to fixing it.
Lastly, dog forbid, we are still somewhat possessed by the evil crashy.
Right now we have a crash in vlc when a song starts playing, maybe 3% of the time. We also have a crash in gklayout.dll that happens sometimes. Just sometimes. That’s the best I’ve been able to figure it out so far. So it’s going to crash on you, too. Be aware. Be very aware.
Did I mention this is just a proof of concept? Did I mention we don’t expect people to think this would be a replacement for their current media player?
Did I say “yet,” yet?
Patience and faith, friends. We’ll get there.
mig
61 Comments
SubscribeXUL+VLC+JS+SQLite and you expect us to don’t call this thing bloated ?!
I was looking for it but now, errr…
Hahahahah, then, if you were me, how would you build a media player?
I have plenty of free space and memory. Can’t wait to get the first version of this installed
Eye candy software, implementing all kinds of modules to play all kinds of media DO take up space and memory. That’s simply the truth of bits and bytes.
Keep up the good work guys! This player is gonna rock!
The only important thing to me is that it “feels” snappy by version 1.0
And let’s all breathe deeply and repeat to ourselves: “1.0 is a long way off.”
I am un a rush to get this, but then again, willing to wait till its ready for use.
In other words - cant wait for its release but am being patient [biting my nails in anticipation LOL]
If this is an issue you have to vocally address, and the response is admittance not reassurance, then you have a problem. I will still check it out on release, but I’m not holding out much hope of success. at all.
Who expects to be successful with a 0.1 product?
My whole point in writing this stuff is to keep you from thinking you’re going to be getting something else once we have something available for download.
From scratch?
Anyway, I can’t wait to preview this… even though it will crash…
iTunes is also bloated… it requires you to have Quicktime installed.
…your proof of concept sounds an awful lot like v1.0 of Sony’s Connect player.
Bloaty (500mb RAM!? It’s only a music player!!), Slow (yes - does the locking me out of the GUI thing a lot) and crashy (tinyhttp.exe has encountered a problem and needs to close… again).
It’s a pity theirs is a 1.0 release.
well… ahemm… RELEASE THAT GODDAM THING ALREADY§§§
people will or won’t tell if it’s bloated or not, crashy or not, etc… and they may help you with plenty of fixing-ideas!
the sooner you’ll have feedback, the better you may improve things.
i personnaly can’t wait to try it and to give you feedback on how it behaves on GNU/linux with a XY,000,000 collection accessed through a network connection (i’m sure you’re dying for such infos
i will personnaly take on any smartass craping on the head of a _0.1_ version of such a cool-promising software! i will!
yours truly
I am very interested in this work you are doing. I cant wait for the first release. Happy Coding
I don’t mean to get al tree-huggy on your ass but what’s up with all the negativity? Defending the bulk, defending the design… geez man let people (or some eager bashers) think what they want!
Keep posting this way and you’ll probably hit a mental wall before this project is even finished
And I say this with good intentions, ’cause Songbird looks VERY promessing and I can’t wait to give it a try. So cheer up!
Anyone who is concerned about “bloated”, “slow”, or “crashy” is probably not the intended audience for the initial release. You early adopters are a little too early. A proof of concept is not a product.
The first release is probably primarily for other developers to play with and (hopefully) start creating interesting extensions or themes.
Hey
I just though I’d post something because it seems there are way too many cynics out there - this looks awesome. As Ani DiFranco would say “If you’re not trying to make something better, than as far as I can tell you are just in the way”
Keep up the hard work
Just like you’re doing it. It’s the extensibility of songbird that’s the real draw, not the underlying pieces of code and how they’re strung together. Firefox is a great browser (for instance) but it’s even better when you start throwing in all the extensions you can use with it.
I fully expect that long before Songbird hits 1.0 it will have many, many cool plugins.
hmm, i’m really looking forward to seeing this player in action. Not because of the features, I just wanna see a XUL-based Player (since I’m a big fan of XUL). I really wanna help you, but I don’t really know a lot of XUL - too lazy to learn, the only thing I know is web-developing (php [...]), but that won’t ever help you
My goodness… how bloated! You should either:
1. Add some fiber to your diet and releive the bloating (though I think fiber increases “crashy-ness”
2. Call it “MEGA-SONGBIRD-9000!!” your slogan can be “mega-songbird: it’s bloated, but it’s crashy.”
muahaha.
The damn thing ain’t even out yet. Bloated and crashy? I expect it to be. I admit I do want it now, and not have to wait for Hurricane Zeta, as TS Zeta is already here.
As computers continue to get smarter, users get dummer and dummer. Let’s just add a bullshit filter to the forum because I can’t take this no more. I check the site everyday waiting for that golden moment and have to be faced with the developers getting defensive from the comments of a few, the proud, the stupid.
Here’s a newflash from dictionary.com:
beta
/bay’t*/, /be’t*/ or (Commonwealth) /bee’t*/ n. 1. Mostly working, but still under test; usu. used with `in’: `in beta’. In the Real World, systems (hardware or software) software often go through two stages of release testing: Alpha (in-house) and Beta (out-house?). Beta releases are generally made to a group of lucky (or unlucky) trusted customers. 2. Anything that is new and experimental. “His girlfriend is in beta” means that he is still testing for compatibility and reserving judgment. 3. Flaky; dubious; suspect (since beta software is notoriously buggy).
Because we said “hi, we think we’re going to publish a media player demo.”
And then the feces hit the windmachine with a bazillion people making a bazillion separate assumptions about all sorts of things that a little demo isn’t going to do out the gate.
Otoh, the next post I get to write is the walkthru, I think, and that should be plenty fun.
not beta.
not beta.
not beta.
I think SQLite should be achieved via extensions…
I mean, not every user needs to SELECT name FROM sb_db WHERE artist=’U2;
Unfortunately, SQLITE gives us database tables. Database tables are what run the APIs.
You might not need a “SELECT WHERE” (actually, you do, the moment you put filters on top of your library), but you still need to store all your metadata and I still have to “SELECT *” to display it.
The user should never have to know SQL to use the product, but the idea of “your library and your playlists are all just database tables” is crucial to programming for Songbird.
So do what you’re gonna do and have fun. Stop asking folks for what they want or how they thing shit should go - that just fans the flames. Just focus on geting what you want out, then move forward from there. Stop make argumentative posts for things that aren’t out yet. The last thing I was thinking about was how bloated this thing would be (like iTunes isn’t?). You’ve done a lot of great work. Be proud of what it is, and let folks go fly a kite if they don’t like it. And above all else, don’t screw yourself by making excuses for the baby before it’s even born yet. It’s all gonna go well, just let it happen and stop stressin’.
Since I’m not a developer, I will not be playing with this release. But you’re in my bookmarks so I’ll be back in a year or so.
songbird doesn’t look bloated to me. download size doesn’t matter. itunes is now over 30MB.
if i have to go through all the menus looking for a feature that’s buried under loads of unorganized other features then i’ll call bloat.
i can’t wait to try songbird and, i hope i’ll be able to contribute to it soon!
better still… pre-alpha
So the whole DB is still powered by SQLite…
SELECT * FROM `sb_db`;
or for searching…
SELECT * FROM `sb_db` WHERE name = ‘%keyword%’ OR artist = ‘%keyword%’ OR album = ‘%keyword%’;
(as many columns as possible :P)
I personally prefer something like
SELECT * FROM `sb_db` WHERE name REGEXP ‘term’;
because that will let users search by regular expressions (although most users don’t need them, some do)
i don’t think 10mb is bloated - but it made me wonder if a portable version of songbird is possible so i can carry it around on a usb stick, now that would be really handy .
I keep visiting and I am liking what I am seeing well done guys… pitty about the trolls
- Tom | http://www.tomwrote.info
when ?
Yes. The whole db is still powered by SQL.
However, nowhere in the app is there anywhere for a user to type an SQL query string.
Giving programmers a “raw” API to control their data (SQL) on top of the “cooked” APIs that we’re writing (so you don’t have to use SQL if you don’t want) doubles the likelihood of people being able to make things that we never imagined.
I’m still sticking with “proof of concept.”
For something so early in its release, I certainly hope people won’t beat up on it for that stuff.
I already have cygwin and VLC. Since you’re custom compiling, I guess I need them both. Though it makes me wonder if changes can be made to VLC itself such that you don’t need to custom compile any of it. Perhaps I’m just misunderstanding the situation.
For our first release, we can’t be sure if you have VLC, so we essentially “install it ourselves.”
We’re doing our best to ensure installing our application won’t mess up your current VLC install, but plugins compiled for a different VLC version don’t work with our specific version.
At the moment.
That’s going to take a whole mountain of digging to make work properly. Once we’re no longer cooking our own specific VLC, this shouldn’t be an issue. But getting the VLC people to accept our edits is a different issue entirely and not something for which we’ll delay first release.
Being able to cook our own moz plugin for our own needs was what drew us to VLC in the first place.
Giving programmers a “raw” API to control their data (SQL) on top of the “cooked” APIs that we’re writing (so you don’t have to use SQL if you don’t want) doubles the likelihood of people being able to make things that we never imagined.
I would very much enjoy the use of a SQL entry box (with REGEXP). I think it would be useful as an… advanced option. Maybe have a tab which says advanced where I can enter my own SQL statement, but the normal user can ignore…
RAM is an issue, even in the days of cheap 1gig sticks. I’m currently running foobar2k with approximately 10k of tracks and it’s using just under 7 megs of ram.
I mention it, because foobar seems to be somewhat overlooked, but it has by far the most powerful database for tracks, and all the important features that get overlooked, like gapless playback, and replaygain.
right. foobar is svelte but inflexible.
we get a browser and a plugin architecture for free, but we have to do extra work for all the niceynicey like crossfading and such.
Right. The idea in the end is to empower the smart people without scaring the less, ah, knowledgable, hmmm?
Aaaamen!
Don’t tell us about 1gb sticks.
There are 256 and 512 computers sold, and some SDR ones.
Right now I have running everything I’m always running - including Firefox and caching proxy. It takes 550Mb of my 256.
When I took 128 of them away, the system didn’t become much slower and didn’t raise the swap usage. Wouldn’t it take all the gigabyte for itself, then?! I’m often running Thunderbird and Gtk-Gnutella with all that.
Sb would run its own XULRunner, and…
Now, if Fx, Tb, and Sb become integrated, it might solve the problem, but they would crash all at once!
I wait for Songbird, but I’m afraid about its memory usage. Hope it will be more stable than XMMS and amaroK in Debian testing (and not use the libraries that make them crash - in Debian Sarge they don’t crash)…
When will there be a roadmap for future versions? Year, please
i hope not u discover than xul is slow (very , very), javascript an interpeted language , and xulrunner “une vraie unsine a gaz”.
no ?
so come on , if you want a fast application go head with qt / c++ or what you want but not with gecko …
Haahaahaaaa aahhaahahaaaa.
Yes, let’s do everything in c++, because it’s the perfect solution for everything. Write all webpages in it, write all queries in it, write every fucking thing in it.
There’s absolutely nothing to gain from using a framework, and scripting languages have no use.
OMG YOU ARE AN IDIOT TOO.
Better Yet, Release a bunch of them, Call ‘em Songbird XP, Songbird 2000, Songbird Vista… etc…. Then Bloated and Crashy become Product Advantages
??????
what are you talking about ?
il use gecko , i develop in xul , c++ , qt etc…
i can say one thing : xul is not for fast , lightweight application…
you tell you taht your beta is slow : i think it is a normal thing ith your component …
but i like xul : only for small appliation .. no more…
Well, my point is that integrating a SQL based database isn’t for a “lightweight” application, either.
It does make the runtime faster for the level of functionality we provide, but since we have to load big databases it makes the loadtime slower.
Essentially the same can be said for XULRunner.
But, no, using gecko and sql are not negotiable. Sorry. Too much functionality relies on them and we’re aiming more for functional than lightweight.
Oh, of course. I mean, 0.1 isn’t out yet.
I guess what I’d like to see is a roadmap of features/functionality
Thank you for the progress updates; they are much more than many other groups would do.
It sounds to me like you have a media player with some very specific unique features. Perhaps you could consider just releasing an app that has those unique features and then hands the user off to their default app for all other things. This might help you focus your creativity and work in the short term.
Well, the whole point of Songbird is to laugh at the people who say “I don’t need songbird, I have wget!”
You shouldn’t have to use 4 different apps to have an “internet media experience”
That being said, while we hope to replace people using amaroK and wget, we don’t expect to replace people using firefox.
While “general web browsing” is a different user experience than “internet media,” we believe adding a fully user-controlled browser to a media player allows the user (optionally, of course) a much richer experience.
I’m not a programmer, so I’m probably talking out of my league…but I am a filmmaker, and I have tried CeltX, which is another Gecko project. And while XUL is almost single-handedly responsible for most of the cool features in CeltX, it is wildly inconsistent, a little “bloated” (compared to its functionality ), and painfully slow…even on my 1.5G Powerbook. As such, I dropped the program and went back to MS Office for scripting, planning, and call sheets. Is there no other, better solution for Songbird? (And for the smartasses in the bunch, this is just a question, so back off. Call me stupid if you will, but I guarantee I’ll make you look foolish if we start talking film direction and post-production. LOL.)
I saw that movie by anonymous and omg it sucked royal balls. His post-production quality is obviously lacking in management skills. Possibly because he scripts his movies in MS Word. Haa haa haa, the loser.
Anonymous should also use less tired techniques such as lame-ass wire-fu with an ugly bitch (his momma).
It’s a valid question, and it deserves an honest answer.
The real reason to embrace XULRunner is to embrace the Mozilla development community and have a 0.1 product in 10 man-months rather than 100.
The “plugins and extensions” architecture is solid and well known by lots of people. It allows us to integrate VLC by snapping our fingers. In the same way, the user interface development is a natural extension from web development.
Having an intensely shortened learning curve for creating extended media player functionality while at the same time inheriting an already established developer community is not a minor benefit.
That being said, XULRunner is essentially as “0.1″ as Songbird is, right now. We expect both products to evolve alongside each other, and we hope to make that process as symbiotic as possible.
Indeed.
Right, see, we don’t want to encourage people to try to build this under Linux, yet.
We’ve got an amazing Caminohead working with us on our Mac build-process. From there we’ll extend that to a generalized (autoconf) build process. Then you can be excited about testing it on Linux.
That’s 0.2 — the “Developer Preview”
0.1 is the “User Preview”
If you know how to sling javascript into HTML to produce amazing functionality on the web, you should be able to easily sling javascript into XUL.
If you’re not too good with the front-end, find someone who is and partner up to make some kind of amazing media service.
XULRunner assumes a set of folders in the user’s documents and settings. If they do not exist, they will be created upon the first run of Songbird on a new Windows machine. Essentially, you’ll lose all your settings on every new machine.
Unfortunately too, if you stuck your stick with media and us into a new machine, all the urls songbird saves in the windows version have the drive letter hard into them. You’d have to make sure you mounted your stick as the same letter on every machine.
Other than that, we’re happily “portable.”
That being said, it’s one of the things that makes a “How To Build Songbird” process rather complicated.
I see your logic. Will Songbird be contributing back to XULRunner?
Oh, and for Troll…we actually considered the title “Sucks Ass Balls” for our next film project, but its not a porn, so what can you do? Plus, it has dialogue, so it probably wouldn’t interest you.
Certainly, we will be contributing ideas from a “first adopter” status. We also intend to either contribute financially or with our own manpower, once we are able.
These are issues we need to work out with MozCorp, and their opinions are going to strongly influence our decisions, so I won’t speculate on the eventual nature of our collaboration.
Blah, you don’t have to prove yourselves to anybody. Just focus on the making the user experience great. Them tech geeks will always find something to nitpick. Keep up the hard work!
Them tech geeks usually aren’t developers but rather obsessive weirdos who like to constantly install and uninstall software and memory on their ‘boxes’ so they can feel like they actually have power over something in their life.