Slashdot Mirror
New G2 RealPlayer Alpha
The Rebel writes "It appears RealNetworks has an updated Alpha G2 RealPlayer for Linux.
Its dated 9-29-99 and you can get it
here." Yep. Fresh dates on the files. Anyone tried this "new" version? Is it really any different from the old one? Should we all run and download it or wait for the beta?
I just downloaded this one a few hours ago after I got a notice that my old version had expired. My main complaint with this version is the CPU usage. 95%?! And that's only because more important things are taking up the other 5%. I don't remember the previous alpha being this slow. The audio quality seems about the same, it works with esddsp (I don't think it did before), and it hasn't crashed on me since I've gotten it (used it for a grand total of 15 minutes, though). But the CPU usage gets to me. I don't think the Windows version uses 95% of my 300mhz processor. Then again, maybe it does and I just didn't notice it before. But the sound gets choppy if I try to multitask while it's playing, which I haven't noticed before.
"Many Linux users found that their Real Player G2 programs stopped working this morning. Apparently Real Networks encoded an expiration date in the code. After some quick calls to Real Networks and some fast foot work by their technical people, the Linux G2 player has been patched so that it will not be expired. "
from linuxtoday
It has been statistically shown that helmets increase the risk of head injury.
Contrary to what you'll read in the comments after the linuxtoday article, the red hat rpm version is also fixed, though they did break a symlink.
.deb package for realplayer, and it will appear in debian unstable this afternoon.
It also appears to have some new features, like playing a little sound clip on startup. And a new "presents" menu.
FWIW, I've uploaded the updated debian
see shy jo
> Do they have a Solaris version out too?
l ayer.html?wp=dl0899&src=990919choice_1&l ang=en
Huh? Where did the link go?
OK, here it is again: http://www.real.com/products/player/downloadrealp
Kai
- Input gain is a lot lower, so I don't have to crank down the master volume every time I want to play a clip (this could have been an oddity specific to my machine with the earlier version).
- Subjectively, overall sound quality is significantly better, with much higher a signal-to-noise ratio. Plus, video quality and stability is much, much better.
- CPU usage is insane, as noted by at least one other person. I have an SMP box, and it's hogging one whole processor, according to "top."
- The "Lowest CPU Usage Best Quality" adjustment in "Preferences" seems to have an effect on quality in this version, with no apparent effect on CPU usage.
Testing environment:I'm curious about the results others have had. It seems like Real just tried to get stuff working with the last version, and has activated optimizations (or something) with this version -- just speculation.
*** Proven iconoclast, aspiring bohemian. ***
This version does seem to be a lot more stable, but the downside as mentioned before by a lot of people already is that it consumes up to one CPU of your system. Not really nice, but running it with an appropriate niceness seems to work fine and leaves the CPU available for other, more important things.
The mp3-decoder though is a little bit noisy and doesn't support playlists, so just use xmms or your favorite dedicated mp3-player.
There's that magnifying-glass icon. It activates a small menu, and you can double the image size. For some reason I associated it with "search" all this time. On Windows, I just right-clicked to bring up the menu, blissfully ignorant of the magnifying glass. I was lost when right-clicking didn't work in Linux.
--
--
=8^
Actually, I believe the word was that a beta would be released by the end of the year.
-Brent--
I gagged when I saw a the pretty orange line on
xosview when running RealPlayer.
WORKAROUND:
Start it up, watch the pretty orange line,
Press pause, wait for the stream to stop.
Press pause again.
Now only 30 % usage (on my ikky P133)
Comment: At least RealPlayer can get through firewalls, XMMS can't (Unless I'm missing something)
I live in Radio hell behind a firewall so RealPlayer is a BIG help. (Gotta drown out my co-workers bitching somehow)
We implemented the latest Real Audio server and encoder under linux (tested NT, random crashes, figured we could automate restarts a lot easier under linux). Purchased 100 stream license, got the box edition mailed, whole nine yards. The install sucked. Couldn't even get it to work without calling their tech support and getting someone to walk us through some manual script edits, just to get the server and encoder to even start (the tech knew exactly what was wrong as soon as I described the problem, knew exactly what to change, why not have just corrected the distribution?) Anyway, we get the server up and running, encoding is going fine, setup a windows client to listen to the live streams we were testing, and everything seemed to check out fine. So we install the box onsite at a local university, get their school radio feed into it, everything looks good and we leave. 30 mins back at the office and the calls start, its not working. Get into the box, the server is still running just fine, the encoder is still running just fine, but the server has just randomly decided to quit listening to the encoder. If one of the processes had died we could have just wrote a little watch dog script to restart it, but the damn processes are still running. So we restart everything, and the streams start playing again. 20mins to 1hr later, more calls. Its down again. Over the next two weeks we try everything under the sun to figure out what is wrong, including numerous emails and calls to Real's tech dept. They let it leak that they know about the problem, and that we need to move to beta products to get around it. I don't want to implement beta products, they've got to beta for a reason, and I'm sick of chasing after their bugs. If you sell a gold version commercial product for a platform, and you charge out the ass for it, it should work (and not randomly require manual restarts...as many as 20 per day). If I had it to do all over again, I would implement netshow on an NT server. And I hate NT with a passion, but I've seen it work at another client location flawlessly without intervention, and it doesn't have a pricing structure based on streams. Sometimes, the linux solution must be better because it is more stable attitude just doesn't hold up. More pressure needs to be put on commercial companies selling linux solutions to stand behind their products. We spent so much time trouble shooting the freakin RA linux server, we couldn't get our money back from the license sales, nor an acceptable solution from them. As it stands, we have had to set a cron job to kill the server, kill the encoder, then start both back up every hour. This keeps knocking people off, but at least they can get a stream for a little while some of the time. Real Networks is WORTHLESS. If you have to implement a live encoding audio streaming server, go with netshow under NT. 2cents
Don't you hate it when people say ``implement'' when they mean ``deploy''?
I sure do.
For example, many radio stations (e.g., NPR) are archiving their broadcasts on the web; this is a situation where ``play the file from the beginning'' doesn't quite cut it. The fact that, with RealAudio, you can skip around in the stream, so that the archive file can be six hours long but you can still find the part you're interested in without listening for six hours straight (or downloading the whole thing to your local disk first) is incredibly important.
As far as I've seen so far, you can't do this with MP3 streams: you can only listen from the beginning. Is that true?
Is there any work being done to make random-access of MP3 streams possible?
The download page was confusing too -- when I filled out the form to download "RealPlayer G2", it took me to a page that said "only RealPlayer 5.0 is supported on this platform", and the file it gave me was named "rv50_redhat5xi386_rpm".
But in fact, that file had 6.0.4.238 in it, which includes the "G2" logo at the bottom.
Why do we care about an upgrade of a particular port of a particular proprietary product? This isn't freshmeat after all.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Gee, maybe because of the large installed base of 2.0 users?
There was a time when people believed that the version numbers of shared libraries meant something: you changed the major number when you had made a binary-incompatible change to the library, and changed the minor number when making backward-compatible changes. That's why ld.so works the way it does.
Apparently the glibc developers don't care about this.