Hi Steve,
after hours of trying I understand there is a issue on the management of sc_trans.
I see when you create or update a DJ in the DJ management session, something is written in client/var/spool/calendar.xml.
If you restart the server, the panel overwrite the same file everytime with the defoult content.
So, if the DJ try to connect doesn't work.

If I update the file with right content and I change permission to 640 (so centova can't overwrite it) it works perfect.  So probably is a bug. Starting the server not need to overwrite calendar.xml.

Is it correct?

Check out http://forums.centova.com/index.php?topic=2003.msg5286#msg5286 below is an exert from
djcraigr's

Well done on the latest build

After a bit of playing around I managed to get MultiDJ's Accounts working it was not an easy thing but the 2 things that I did do was

1: change the following line
calendarrewrite=0 this was commented out (; calendarrewrite=1)
2:change the following line
djcipher=b******************f so that it was commented out all 3 account that i have tested work fine.

questions are welcome.

Craig

Yes, I read that post and it works.
But I think clients don't need a workaround. Dj managements have to work without changing the config file.
So probably must be the default settings in the panel configuration of the source ( for sc_trans).

Not a bug.  If you don't want Centova Cast to write to your calendar.xml, then use the solution that djduck suggested above.  Doing so will eliminate Centova Cast's ability to configure DJ login hours, though, so that part of the "DJ Management" page of each of your streams' client areas will no longer function.

Sorry Steve, probably I'm not clear with my english.
I mean:
If I leave the default setting of config of sctrans (  ;  calendarrewrite=1 ) everytime i restart the server centova cast reset the xml to default (empty) so if I set 1 or more dj with or without login hours... Restarting server all settings are deleted.
Do you  say that  it needs to enable every time the possibility to create dj logins manually editing the configuration file?  ( settings calendarrewrite=0) or there is something wrong I don't understand.

It seems simple. No dj on dj managements = no live logins.
Dj added on j managements = ability to login live for them.

It doesn't work like this now. If I set a dj, after restart of server it ca not go live ( and xml is empty).

Sorry Steve, probably I'm not clear with my english.

Your English is great, I think I'm just misunderstanding in general.

If I leave the default setting of config of sctrans (  ;  calendarrewrite=1 ) everytime i restart the server centova cast reset the xml to default (empty)

Couple of issues here... first, Centova Cast doesn't do anything to your calendar.xml file when the stream starts or stops.  It *will* rewrite it every time you update your account settings in Centova Cast, or every time you add/modify/remove a DJ in the DJ Management page.

Second, Centova Cast should not reset calendar.xml to an empty file, ever.  Even if you have no DJs on file, it should write out an XML preamble followed by an empty eventlist element, eg:

Code: [Select]

<?xml version="1.0" encoding="UTF-8" ?>
<eventlist>
</eventlist>

If it's ending up as an empty (0-byte) file, there must be something going wrong somewhere... possibly inside Centova Cast, possibly outside of it.

so if I set 1 or more dj with or without login hours... Restarting server all settings are deleted.

That shouldn't happen and I can't reproduce it here.  It sounds very much like you have calendarrewrite=1 (uncommented) in your source.conf file -- that COULD cause this type of behavior if sc_trans2 decides it doesn't like what it sees in calendar.xml, as it gives sc_trans2 free reign to rewrite the calendar.xml file as it sees fit.

Do you  say that  it needs to enable every time the possibility to create dj logins manually editing the configuration file?  ( settings calendarrewrite=0) or there is something wrong I don't understand.

The default setting is "; calendarrewrite=1" (eg: the calendarrewrite option completely commented out) which should be identical to explicitly setting calenderrewrite=0.  I've changed the default to explicitly use "calendarrewrite=0" for new streams in the next build.

Anyway, with the default setting, the only thing that is disabled is the ability to use sc_trans2's AJAX API to modify calendar events.  Other than that, you should never have a need to change this setting.

Steve could you please take a look at the quick links section under ...
Server type:    SHOUTcast (v1)

The DJ port needs to be +2, currently it lists the SHOUTcast port (ie. 8000) -- shouldn't that be +2 (ie. 8002)
The password format is also incorrect, it should be the username:password that the user created in the DJ manager, currently is says to use the stream password


By the way this method is working great for my 2 servers, I still need to make a couple changes in the config for each user (mentioned above) but I think you said you would correct that in the next build. This method works with just about any software as v2 support is not required, many thanks also my servers are running much better with the latest rc2

Steve could you please take a look at the quick links section under ...
Server type:    SHOUTcast (v1)

Before I say anything more, please note that this section changes depending on whether or not sctrans2 is in use on the stream.  If it's enabled (eg: the stream has been provisioned with "sctrans2" as the source type, and the source status is NOT set to "Prohibited"), you'll get the information for connecting a live source through sctrans2; if it's disabled, you'll get the information for connecting a live source directly to DNAS 2.

I did, after investigating your issue, find that this logic was not functioning correctly and it was incorrectly detecting sctrans2 -- that's at least part of the reason it wasn't displaying what you expected to see.

The DJ port needs to be +2, currently it lists the SHOUTcast port (ie. 8000) -- shouldn't that be +2 (ie. 8002)

First, note that because you were using sctrans2, it should have actually been displaying portbase+4 so that the source connection goes through sctrans2 rather than DNAS2.  Since DNAS2 already has a source connection (from sctrans2), making another connection to DNAS2 wouldn't work.  With the correct sctrans2-detection logic in there now, it's correctly displaying +4.

That said, I don't think there's ever a case in which the DJ port should be +2, even when NOT using sctrans2.  According to this section of the DNAS2 documentation:

SHOUTcast 1 sources are only able to connect to 'portbase + 1'.

So it seems that it definitely shouldn't be displayed as +2, although a case could be made for displaying it as +1.  And in fact, we used to display +1 in a prior version.  The reason we switched back to the portbase is because in testing various live source applications, we found that they automatically add 1 to whatever port number you give them.  This is presumably to simplify things for DJs who may assume the port is 8000 since the server is on port 8000.

If you've found that this isn't universally the case, then we'll have to revisit this... hopefully not though, as it'd mean that *someone* is always going to be seeing the wrong port number for their source application.

The password format is also incorrect, it should be the username:password that the user created in the DJ manager, currently is says to use the stream password

The text for this was already in there, it just wasn't being displayed due to the aforementioned bug.  Fixed for the next build -- thanks!

the norm for a v1 based source is to connect on portbase+1 for you (since the v1 DNAS used portbase for clients and portbase+1 for sources and expected sources to use portbase as the input value so as to avoid confusion when connecting to the DNAS).

with the v2 DNAS, that still holds (currently) when using a v1 source in you enter 'portbase' and it will connect on portbase+1. though for a v2 source if you enter 'portbase' then it'll connect on 'portbase' since we can ident the stream it relates to which isn't possible with the v1 stream type.

now the same thing applies to sc_trans which is where it gets rather clunky. for a v1 DJ source, it is then going to be djport you enter but you actually connect on djport+1 and for a v2 DJ source you enter 'djport2' and connect on 'djport2'.


i have internal sc_trans builds working so it'll work like the DNAS where you just set 'djport' and that's what you enter in either a v1 DJ source or a v2 DJ source which makes it a lot simpler to a) setup and b) use (i don't know why it wasn't done like that in the first place but c'est la vie).


however, things may get more complex again as far as the v2 DNAS is concerned, since i recently added to the internal builds the means to specify a 'legacyport' for any stream numbe. the effect of that is it's possible to connect a v1 source on stream #2 and so on. the potentially confusing part is that i've done it so you configure the actual port to connect on so in the v1 source it would need to be entered as 'legacyport-1' - though there's a source summary page in the builds which indicates the legacyport to enter in the client instead of the configuration option.


alas this is the fun from trying to main compatibility with all of the older v1 sources people are still using but where they want to run multiple streams. just thought i'd try to clarify why the port allocations are somewhat clunky / confusing and have led to some issues.

-daz

Ok Steve.  This is what I mean step by step:

I have cc3 latest build installed

1 - I create a new account shoutcast2, sctrans2

2 - The config file of sctrans is  by default :  ; calendarrewrite=1    (commented)

3- The xml file content is:
  <eventlist />

4- Upload mp3s and start the server. Xml content is always:
  <eventlist />

5- I create a DJ: DJtest with all powers.

7- Now the xml file content is:
<eventlist>
  <event type="dj">
    <dj archive="0">djtest</dj>
    <calendar repeat="127" />
  </event>

</eventlist>

8- I restart the server

9- The xml content now is:
<?xml version="1.0" encoding="UTF-8" ?>
<eventlist>
</eventlist>

The behavior is the same if befor step 8 I enter in configuration setup and click SAVE.
And the same if I change config file to:   calendarrewrite=0  (not commented)

You can add 1 or more DJ...  but every restart of the server the xml file is set to:
<?xml version="1.0" encoding="UTF-8" ?>
<eventlist>
</eventlist>

And then djs cannot connect.

The only way to get them always working is to set permissions of xml on 640 before restarting server.  In that case xml is not rewritten so DJs can connect.

I try this on both my cc3 panels and is the same.

I hope now you can understand what I meaning.   

8- I restart the server

9- The xml content now is:
<?xml version="1.0" encoding="UTF-8" ?>
<eventlist>
</eventlist>

Interesting.  Apparently I can't read.  For some reason I believed commenting out calendarrewrite=1 would default to calendarrewrite=0 -- I was SURE I read that somewhere -- but the sctrans2 wiki clearly states that this is not the case.

So without calendarrewrite=0, sc_trans2 will indeed rewrite the calendar.xml file on exit, and that's what's causing this problem.  Sure enough, setting it to 0 on my test installation fixes this behavior.

As for why sctrans2 is removing the DJ entry at all, I'm not sure... as far as I'm aware it shouldn't do that.  Perhaps sctrans2 doesn't like something about how we're formatting our XML, or perhaps it's just a bug in sctrans2... DrO, are you out there?

i think the best answer for the moment is because sc_trans is beta and the calendar file handling isn't really finished. if there's nothing in the file then it's likely that it's not been seen by sc_trans like if it was added after it was started i.e. not via the ajax api - that's the only thing i can think off currently. but like i started with, the handling really isn't too ideal since it needs to re-add anything in the configuration file if not present e.g. dj and playlist events. though the best thing to do is tell it not to re-write on exit for the time being so you've the control over the file (hence the option ).

-daz

if there's nothing in the file then it's likely that it's not been seen by sc_trans like if it was added after it was started i.e. not via the ajax api

Aha!  That's exactly the problem -- we're writing to it after sc_trans starts so it's not seeing the update, and then sc_trans is writing out the DJ configuration that it has in memory upon exit.  Mystery solved then.

I've already changed the default to calendarrewrite=0 in the skeleton sc_trans configuration file, so all new streams will pick this up automatically.  For existing streams, admins can edit /usr/local/centovacast/var/vhosts/USERNAME/etc/source.conf and manually set calendarrewrite=0.