Izzy did some digging:

• Auto-Rotate setting has been ignored due to a little typo by rob. Fixed in revision:657
• The PHP function used for image rotation is only included in PHP >= 4.3, and even here only when GD is built-in (not as module). Fixed in revision:658
• Still open: Some Apache problem: when accessed by the BLT, the server port is reported incorrectly. No idea why.

Just changed the topic to reflect the true issue. The $url generated in gen_photolist.php contains the wrong port number of the server. No idea what's going on there: I dumped the $_SERVER variable when accessing SwissCenter from the BLT, and that shows the server port is messed up (reports 80 instead of 8080). When accessed with Firefox, the port it correctly reported with 8080. The difference is in this test, that Firefox accesses the same machine it is running on itself, while the BLT is a different machine. So I tried a wget from my BLS (Buffalo Link Station), which also returned the wrong port. Tried the same from my Dreambox - also wrong port. Looks like there's some problem with PHP, always reporting the wrong SERVER_PORT when accessed by a remote machine. This may be specific to Ubuntu again - or maybe not, so if somebody else could verify?

This works correctly on both my Showcenter 200 and Showcenter 1000g, as well as from remote machines. I don't think this is specific to the BLT as it's apache/php that populates the _SERVER variables.

It could be:

1. an issue with Ubuntu - I can test that later as I have ubuntu running on a virtual machine.
1. an issue with your version of PHP (can you upgrade to the latest 4.x release?)
1. an issue with your apache installation.

From my point of view, the good news is that it isn't the swisscenter code! I can't help it if the server reports the wrong port number can I? ;)

We could solve this problem by adding a new option URL_PORT_OVERRIDE. Possible settings: 'Default' (will empty the setting), or a specific port (2-4 digits). Then, instead of relying on $_SERVER[ 'SERVER_PORT'], we call get_sys_pref('URL_PORT_OVERRIDE',$_SERVER[ 'SERVER_PORT']. If URL_PORT_OVERRIDE is not set (or setting it to DEFAULT emptied the setting), the $_SERVER variable is used (as it is now). Otherwise, we use the user specified value.
Even if that's something like working around 3rd party bugs instead of fixing them, this gives us an additional feature: One could run multiple instances of SwissCenter, using one dedicated instance for content delivery - and the other for 'browsing only', while the latter leaves the content delivery to the first. Something like 'simple load balancing' ;)

If we do so, and count it as 'additional functionality', there are some things to add to the documentation/README/configuration screen as hints:

• both servers need access to the same database ('shared access')
• to prevent messed-up data (since we don't use transactional data handling), only one SC installation should have r/w access. All other application instances should only be provided with a read-only login.
• user must remember the 'master installation' if (s)he wants to modify anything

Replying to [comment:5 izzy]:
>To prevent messed-up data (since we don't use transactional data handling), only one SC installation should have r/w access. All other application instances should only be provided with a read-only login.

No - the streaming server would require write access - it's the part that's responsible for updating the number of viewings of a file.

Hm... so if we still use a different user for that and grant that user select/update/insert/delete only to the necessary objects?

Izzy - could you post/attach the contents of the $_SERVER array to this bug please. It might be possible to use a different variable instead (such as HTTP_HOST).

Guess my feedback is not needed anymore - looks like you've found a way to fix it. Seems to work fine now with BLT, so this ticket can be closed (fixed in revision:691).

Updating tickets (#63, #185, #57, #67, #194, #26, #35, #56, #58, #110, #118, #121, #152, #214, #227, #233, #36, #68, #186, #199, #2)

Updating tickets (#63, #65, #75, #84, #87, #89, #93, #185, #10, #57, #64, #69, #70, #74, #79, #80, #82, #83, #85, #86, #88, #90, #91, #96, #97, #98, #99, #100, #101, #104, #105, #109, #115, #116, #117, #120, #126, #128, #130, #131, #133, #135, #153, #163, #169, #171, #173, #179, #180, #181, #184, #187, #188, #194, #195, #198, #203, #205, #218, #220, #226, #231, #236, #239, #240, #242, #247, #252, #5, #6, #11, #20, #25, #26, #27, #29, #30, #38, #40, #42, #43, #44, #46, #49, #50, #51, #52, #53, #55, #58, #59, #60, #61, #71, #92, #102, #103, #106, #107, #108, #112, #113, #114, #118, #119, #121, #129, #137, #140, #141, #144, #145, #146, #147, #149, #150, #151, #152, #154, #156, #157, #158, #160, #161, #162, #165, #167, #168, #172, #176, #182, #183, #191, #192, #193, #196, #197, #204, #206, #210, #215, #217, #222, #228, #230, #232, #234, #235, #237, #243, #249, #1, #4, #9, #12, #13, #16, #62, #78, #164, #166, #189, #190, #199, #200, #208, #209, #211, #212, #19, #47, #48)