I kind of realized i now have another problem to deal with.
As I have it set up, when a visitor enters, that creates a playlist for
that visitor.
What happens when another visitor is online?
I tried it with both IE and FF at the same time.
While the list is dffierent, there is no audio in the second browser.

So I figure I will have to give each browser a unique id to the playlist.
But how?
Would the server crash with s few thousand visitors online at the same
time?

The wimpy player can embed the playlist into the html, but their way of
doing it doesn't allowo me to display the file names unless the gilename
match exactly.
that is, I could not show "exodus - henry mancini". I'd have to show
65-001mp3 because that's how I have the naming convention set up.

> I kind of realized i now have another problem to deal with.> As I have it set up, when a visitor enters, that creates a playlist for> that visitor.> What happens when another visitor is online?> I tried it with both IE and FF at the same time.> While the list is dffierent, there is no audio in the second browser.> > So I figure I will have to give each browser a unique id to the playlist.> But how?> Would the server crash with s few thousand visitors online at the same> time?> > The wimpy player can embed the playlist into the html, but their way of> doing it doesn't allowo me to display the file names unless the gilename> match exactly.> that is, I could not show "exodus - henry mancini". I'd have to show> 65-001mp3 because that's how I have the naming convention set up.

Look into session ID. When someone comes to your site, they have to
login, yes? Tie the session ID created by php to the username. Use
that to create a unique MD5 hash for a playlist you store under their
username in MySQL.

You do realize that all this will require sychronizing things and MySQL
(or some other DB that deals with record locking)?

> In article <39cy6hpu04oe$(dot)18k40zgdny9go$(dot)dlg(at)40tude(dot)net>,> richard <noreply(at)example(dot)com> wrote:> >> I kind of realized i now have another problem to deal with.>> As I have it set up, when a visitor enters, that creates a playlist for>> that visitor.>> What happens when another visitor is online?>> I tried it with both IE and FF at the same time.>> While the list is dffierent, there is no audio in the second browser.>> >> So I figure I will have to give each browser a unique id to the playlist.>> But how?>> Would the server crash with s few thousand visitors online at the same>> time?>> >> The wimpy player can embed the playlist into the html, but their way of>> doing it doesn't allowo me to display the file names unless the gilename>> match exactly.>> that is, I could not show "exodus - henry mancini". I'd have to show>> 65-001mp3 because that's how I have the naming convention set up.> > Look into session ID. When someone comes to your site, they have to > login, yes? Tie the session ID created by php to the username. Use > that to create a unique MD5 hash for a playlist you store under their > username in MySQL. > > You do realize that all this will require sychronizing things and MySQL > (or some other DB that deals with record locking)?

At this time, I am not looking at visitors needing to sign up and login.
I will look into session id and see if that will help.

> I kind of realized i now have another problem to deal with.> As I have it set up, when a visitor enters, that creates a playlist for> that visitor.> What happens when another visitor is online?> I tried it with both IE and FF at the same time.> While the list is dffierent, there is no audio in the second browser.> > So I figure I will have to give each browser a unique id to the playlist.> But how?

At the beginning of the webpage, before /anything/ has been sent to the
client, have your PHP code execute a session_start() call. Note that this
*absolutely must* be the first thing done; if you send out even one blank
line, this does not work.

session_start() generates a cookie, records the cookie identifier on the
server side, and sends the cookie to the client in the HTTP headers.
Because the cookie has to go out in the headers, you cannot send any data
before it.

Now, in your page's body PHP, you can test certain values that PHP provides
that all relate to that cookie. The easiest way is to check the existance
and contents of the $_SESSION associative array.

$_SESSION will be null (as will any keyed $_SESSION value) on the client's
initial entry to the page. Thus, an isset() test within the body will be
able to determine if the client has retrieved the initial page, or has
retrieved a second or subsequent time.

As $_SESSION is an associative array, you can store values in it. Each time
the client returns and rereads the page, you get the values /for that
client/ as values of $_SESSION.

/* save the session's start row for next time */
$_SESSION['RowNum'] = $EndRow;

.....

> Would the server crash with s few thousand visitors online at the same> time?

It depends on how you've configured your server. If you have your http
server set up to handle a large number of connections, and enough temporary
space for a large number of session state records (saved as small files),
and have configured the database server for the large number of database
connections, you should have no problem servicing thousands of simultaneous
clients.

[snip].

--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

On 2013-10-01 00:12, richard wrote:> As I have it set up, when a visitor enters, that creates a playlist for> that visitor.> What happens when another visitor is online?> I tried it with both IE and FF at the same time.> While the list is dffierent, there is no audio in the second browser.

You didn't mention anything about sessions, so I'm going to assume that
all you're doing is creating a fresh random playlist for each new
request. If that's the case, then you don't have to worry about
concurrent visitors at all.

Why doesn't it work? Hard to say with the minimal information you're
giving us. The first thing that comes to mind is that one of the
browsers (most likely the one you don't usually test with) has a problem
playing what you send it. In other words, it's most likely a client side
problem or a playlist format problem. Check your browser settings and
plugins - in the "other" browser.

> On Mon, 30 Sep 2013 16:16:23 -0700, Michael Vilain wrote:> >> In article <39cy6hpu04oe$(dot)18k40zgdny9go$(dot)dlg(at)40tude(dot)net>,>> richard <noreply(at)example(dot)com> wrote:>> >>> I kind of realized i now have another problem to deal with.>>> As I have it set up, when a visitor enters, that creates a playlist for>>> that visitor.>>> What happens when another visitor is online?>>> I tried it with both IE and FF at the same time.>>> While the list is dffierent, there is no audio in the second browser.>>> >>> So I figure I will have to give each browser a unique id to the playlist.>>> But how?>>> Would the server crash with s few thousand visitors online at the same>>> time?>>> >>> The wimpy player can embed the playlist into the html, but their way of>>> doing it doesn't allowo me to display the file names unless the gilename>>> match exactly.>>> that is, I could not show "exodus - henry mancini". I'd have to show>>> 65-001mp3 because that's how I have the naming convention set up.>> >> Look into session ID. When someone comes to your site, they have to >> login, yes? Tie the session ID created by php to the username. Use >> that to create a unique MD5 hash for a playlist you store under their >> username in MySQL. >> >> You do realize that all this will require sychronizing things and MySQL >> (or some other DB that deals with record locking)?> > At this time, I am not looking at visitors needing to sign up and login.> I will look into session id and see if that will help.

Most session IDs without a login aren't sufficiently unique. You'll
need to have additional criteria to ensure that to machines with the
same browser and hardware connecting to your server from the same IP
address are able to be differentiated between the two. That's up to
you. You sound like you need to do a lot of reading up on this before
you come up with a viable solution. Publically available stuff without
first authenticating the user will only get you so far.

On 9/30/2013 11:37 PM, Michael Vilain wrote:> In article <tabtkdru0f5g$(dot)1x6bq88mzzryc$(dot)dlg(at)40tude(dot)net>,> richard <noreply(at)example(dot)com> wrote:> >> On Mon, 30 Sep 2013 16:16:23 -0700, Michael Vilain wrote:>> >>> In article <39cy6hpu04oe$(dot)18k40zgdny9go$(dot)dlg(at)40tude(dot)net>,>>> richard <noreply(at)example(dot)com> wrote:>>> >>>> I kind of realized i now have another problem to deal with.>>>> As I have it set up, when a visitor enters, that creates a playlist for>>>> that visitor.>>>> What happens when another visitor is online?>>>> I tried it with both IE and FF at the same time.>>>> While the list is dffierent, there is no audio in the second browser.>>>> >>>> So I figure I will have to give each browser a unique id to the playlist.>>>> But how?>>>> Would the server crash with s few thousand visitors online at the same>>>> time?>>>> >>>> The wimpy player can embed the playlist into the html, but their way of>>>> doing it doesn't allowo me to display the file names unless the gilename>>>> match exactly.>>>> that is, I could not show "exodus - henry mancini". I'd have to show>>>> 65-001mp3 because that's how I have the naming convention set up.>>> >>> Look into session ID. When someone comes to your site, they have to>>> login, yes? Tie the session ID created by php to the username. Use>>> that to create a unique MD5 hash for a playlist you store under their>>> username in MySQL.>>> >>> You do realize that all this will require sychronizing things and MySQL>>> (or some other DB that deals with record locking)?>> >> At this time, I am not looking at visitors needing to sign up and login.>> I will look into session id and see if that will help.> > Most session IDs without a login aren't sufficiently unique. You'll> need to have additional criteria to ensure that to machines with the> same browser and hardware connecting to your server from the same IP> address are able to be differentiated between the two. That's up to> you. You sound like you need to do a lot of reading up on this before> you come up with a viable solution. Publically available stuff without> first authenticating the user will only get you so far.>

Incorrect. Sessions don't know anything about logins; it's just data to
them. And the session ID needs to be unique for each visitor, whether
or not they are logged in.

Can you imagine, for instance, a shopping cart where multiple people
share the same session id - and therefore cart? Many sites don't
require any information until it's time to check out.

On 09/30/2013 06:12 PM, richard wrote:> I kind of realized i now have another problem to deal with.> As I have it set up, when a visitor enters, that creates a playlist for> that visitor.> What happens when another visitor is online?> I tried it with both IE and FF at the same time.> While the list is dffierent, there is no audio in the second browser.> > So I figure I will have to give each browser a unique id to the playlist.> But how?> Would the server crash with s few thousand visitors online at the same> time?> > The wimpy player can embed the playlist into the html, but their way of> doing it doesn't allowo me to display the file names unless the gilename> match exactly.> that is, I could not show "exodus - henry mancini". I'd have to show> 65-001mp3 because that's how I have the naming convention set up.>

I'd say the Wimpy Player is living up to its name... I get no sound
in *any* browser. Not FF, not GC and not Thunderbird.

On 9/30/13 11:37 PM, Michael Vilain wrote:> Most session IDs without a login aren't sufficiently unique. You'll > need to have additional criteria to ensure that to machines with the > same browser and hardware connecting to your server from the same IP > address are able to be differentiated between the two. That's up to > you. You sound like you need to do a lot of reading up on this before > you come up with a viable solution. Publically available stuff without > first authenticating the user will only get you so far.>

Session IDs with or without login MUST be unique, or your sessions are
broken (session logic MUST give a new id number to anything starting a
session, or you don't have real sessions). Multiple connections from the
same IP will be given different sessions.

Using a session ID without a login will mean that any work the user does
will be forgotten when the session expires.

What adding a login does is to allow you to put into the session a user
id from the login, so that the data from the user can persist from one
session to another.

Am 01.10.2013 14:05, schrieb Richard Damon:> Session IDs with or without login MUST be unique, or your sessions are> broken (session logic MUST give a new id number to anything starting a> session, or you don't have real sessions). Multiple connections from the> same IP will be given different sessions.> > Using a session ID without a login will mean that any work the user does> will be forgotten when the session expires.> > What adding a login does is to allow you to put into the session a user> id from the login, so that the data from the user can persist from one> session to another.

On 10/1/2013 8:05 AM, Richard Damon wrote:> On 9/30/13 11:37 PM, Michael Vilain wrote:>> Most session IDs without a login aren't sufficiently unique. You'll>> need to have additional criteria to ensure that to machines with the>> same browser and hardware connecting to your server from the same IP>> address are able to be differentiated between the two. That's up to>> you. You sound like you need to do a lot of reading up on this before>> you come up with a viable solution. Publically available stuff without>> first authenticating the user will only get you so far.>> > > Session IDs with or without login MUST be unique, or your sessions are> broken (session logic MUST give a new id number to anything starting a> session, or you don't have real sessions). Multiple connections from the> same IP will be given different sessions.> > Using a session ID without a login will mean that any work the user does> will be forgotten when the session expires.> > What adding a login does is to allow you to put into the session a user> id from the login, so that the data from the user can persist from one> session to another.>

Just adding an id from the login to the session won't do a thing. When
the session expires, the data will be lost.

If you want the data to continue across sessions, you need to store it
yourself, i.e. in a database.

On 10/1/13 12:09 PM, Jerry Stuckle wrote:> On 10/1/2013 8:05 AM, Richard Damon wrote:>> On 9/30/13 11:37 PM, Michael Vilain wrote:>>> Most session IDs without a login aren't sufficiently unique. You'll>>> need to have additional criteria to ensure that to machines with the>>> same browser and hardware connecting to your server from the same IP>>> address are able to be differentiated between the two. That's up to>>> you. You sound like you need to do a lot of reading up on this before>>> you come up with a viable solution. Publically available stuff without>>> first authenticating the user will only get you so far.>>> >> >> Session IDs with or without login MUST be unique, or your sessions are>> broken (session logic MUST give a new id number to anything starting a>> session, or you don't have real sessions). Multiple connections from the>> same IP will be given different sessions.>> >> Using a session ID without a login will mean that any work the user does>> will be forgotten when the session expires.>> >> What adding a login does is to allow you to put into the session a user>> id from the login, so that the data from the user can persist from one>> session to another.>> > > Just adding an id from the login to the session won't do a thing. When> the session expires, the data will be lost.> > If you want the data to continue across sessions, you need to store it> yourself, i.e. in a database.> >

Yes, I guess I assumed that someone would be smart enough to realize
that to store data for longer than a session would realize that they
needed to put the actual data somewhere besides the session itself.

On 10/2/2013 8:33 PM, Richard Damon wrote:> On 10/1/13 12:09 PM, Jerry Stuckle wrote:>> On 10/1/2013 8:05 AM, Richard Damon wrote:>>> On 9/30/13 11:37 PM, Michael Vilain wrote:>>>> Most session IDs without a login aren't sufficiently unique. You'll>>>> need to have additional criteria to ensure that to machines with the>>>> same browser and hardware connecting to your server from the same IP>>>> address are able to be differentiated between the two. That's up to>>>> you. You sound like you need to do a lot of reading up on this before>>>> you come up with a viable solution. Publically available stuff without>>>> first authenticating the user will only get you so far.>>>> >>> >>> Session IDs with or without login MUST be unique, or your sessions are>>> broken (session logic MUST give a new id number to anything starting a>>> session, or you don't have real sessions). Multiple connections from the>>> same IP will be given different sessions.>>> >>> Using a session ID without a login will mean that any work the user does>>> will be forgotten when the session expires.>>> >>> What adding a login does is to allow you to put into the session a user>>> id from the login, so that the data from the user can persist from one>>> session to another.>>> >> >> Just adding an id from the login to the session won't do a thing. When>> the session expires, the data will be lost.>> >> If you want the data to continue across sessions, you need to store it>> yourself, i.e. in a database.>> >> > > Yes, I guess I assumed that someone would be smart enough to realize> that to store data for longer than a session would realize that they> needed to put the actual data somewhere besides the session itself.>

If you are referring to Richard (Mr Oldies), we are still trying to get
help him remember the difference between '=' and '=='.

On 10/3/2013 11:00 AM, Twayne wrote:> On 2013-10-03 8:27 AM, Scott Johnson wrote:>> On 10/2/2013 8:33 PM, Richard Damon wrote:>>> On 10/1/13 12:09 PM, Jerry Stuckle wrote:>>>> On 10/1/2013 8:05 AM, Richard Damon wrote:>>>> > On 9/30/13 11:37 PM, Michael Vilain wrote:> ...> >> >> If you are referring to Richard (Mr Oldies), we are still trying to get>> help him remember the difference between '=' and '=='.>> >> But I am still optimistic with hope.>> >> Scotty> > Or how about '===' and '!==="? Funny how one of them doesn't work!> > Twayne`