Newbie Wammer
  • Content Count

  • Joined

  • Last visited

Community Reputation

62 Excellent

About Briain

  • Rank
    DJ Duggie Dinbins

Personal Info

  • Location
  • Real Name

Wigwam Info

  • Power Amp/s
    2250 + 212 (Bedroom)
  • My Speakers
    350A + 345 (Lounge)
  • Trade Status
    I am not in the Hi-Fi trade

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi @golke53 and @DavidHB Well, my reasoning was based on many years of sorting odd SSDP discovery problems (and not just for Linn devices; media servers need that to all work well, too) and as illustrated by what I'll type next, there isn't a simple quick fix answer to all such issues as there are a heck of a lot of variables, but certainly in the past, the ISP router blocking discovery was a common problem. As I mentioned, I have no such issues, so unfortunately it is not possible for me to analyse the waiting for room issue as I am not waiting for my room; it always materialises in a timely manner! That said, over the years I have seen many instances of SSDP discovery being blocked by the switch sections of ISP routers (and even a couple of moderately expensive Zyxel router models; they had introduced a QoS feature and it's poor implimentation was blocking SSDP between its switch ports) and in all these odd cases, it could be fixed by not using the router's internal switch section and instead using a separate unmanaged switch. I can only assume that failure of the SSDP discovery process is behind the 'waiting for room' issue and as I noted in my previous post, adding a switch typically resolved that issue, but yes indeed, likely that will not be the cause of all cases of the problem (as mentioned, wireless could indeed be the problem; there are a lot more variables with the wireless aspect, so that very possibly is causing problems in some installations . Just one example of a [fairly recent; I can't recall the timescale, but within the past couple of years, from memory] subtle wireless issue caused when Apple changed their wireless networking behaviour in iThings and that as a result of the change (though my understanding is it was far more complex and subtle than just that single change in isolation) their iThing products were coming to all sorts of grief on some manufacturers' WAPs (including enterprise grade products). Eventually, it transpired could be helped by changing the WAP's DTIM setting from the default of 1 to 3 (and I did that at a couple of iThing heavy sites with very good results). I now actually run my own network with DTIM set to 3 as it can potentially also improve the iThing's battery discharge times, but it does result in ancient Android devices being unable to associate to the WAP (though by now, nobody should be running Android devices of that vintage). Just one example of a subtle setting that can muck things up (in that case, iThing went to sleep, then when woken it wasn't associated to the network). Problems can also happen with managed switch firmware builds. About 2 years ago, I tried Songcast from a PC to an ADSM and that ended in grief (it only played for 30 seconds then the stream stopped) and I only found out why by using Wireshark to look at what was going on on the network. In that case, the failure coincided with an undocumented feature in the L2 managed switch I was using at that time (it was actually a D-Link propriety discovery protocol - a packet sent out looking for other D-Link devices every 30 seconds - which was only present and brought out onto the GUI of the next model up from my switch (a L3 model) but even though it couldn't be disabled in my model, they had added it anyway) so my point is that a lot of things are going on in networks and that changing some of these things can have unintended and unexpected consequences, which is why I like to only use tried and tested products that I know will work and I've settled on (mostly Dratyek routers, D-link and Cisco switches and Ubiquiti WAPs, these days). That said, even though I like Ubiquiti WAPs, they have also released some flaky firmware builds which have caused all sorts of unexpected and intermittent problems, so I have to keep up to speed with what's being said on their forum before updating my customers or myself (and I often discuss it with Chris at Linn Products; their factory uses Ubiquiti and like myself, he also now holds back on updating things until each release has been out for a while and all the forum posts about it have been read; I remember one release causing all sorts of grief at the Linn factory, last year). The basic principle of networking is very simple, but there are a lot of additional things 'available' and mistakes (or not enough testing) made when implementing such features can occasionally cause utter chaos (or cause chaos only for certain models of client device) so no, there is no magic bullet recommendation one can state will solve all issues, but an unmanaged switch at least bypasses many of the potential issues that can arise from badly done router firmware builds (and remember, many an ISP router is basically a retail model with their bespoke firmware to hide 'complicated' features from the GUI and sometimes to add 'user handy' DNS features to redirect customers who incorrectly type URLs to their own home page, for example). Wireless networking is an even bigger subject (the old 802.11a/b/g book I have comprises about 640 pages and I have several other books about 11n and 11ac) so though these things all look quite simple on the surface, dig deeper and you find that there is quite a degree of complexity and subtlety, a heck of a lot going on underneath the covers and with a lot of manufacture set parameters (over and above the ones available in the GUI) any of which could cause conflict with the manufacturer set parameters in the wireless client. Of course, you then have to consider situations where the signals are weak and/or there is interference present (which most people will suffer from, to varying degrees; in certain - perhaps many - circumstances, this might be improved when WiFi 6 appears, so I'll add a note at the end in case anyone is interested) and what with the other possible problems, adding the signal 'quality' ones and you have so many variables that it is difficult for me to remotely diagnose what might be going 'wrong' with a wireless network. Of course, like with most faulting activities, the easiest way to track things down is by substitution, so the best one can do is to recommend the cheapest, easiest (and hopefully most likely responsible) part of the system to first substitute (a switch to bypass the router's switch ports) and in the past, that has indeed cured a lot of ills without need for further work, however, this new waiting for room issue is one I have yet to experience for myself, so no, I most certainly cannot be sure which network component is causing it, though I'd expect some form of SSDP failure is behind it (historically it was getting blocked by the switch section, but it could indeed be getting blocked by the wireless section in some modern ISP routers, or it could indeed be a manufacturer selected setting that causes the control point devices to get unhappy, like battery conservation and sleep/resume resulting in a delay in network availability). Kind regards to all, Briain Incidentally, not much has been broadcast about the so-called WiFi 6 (AKA 802.11ax) but what has been said doesn't pick up some very interesting new features that it will bring to the party. Okay, I love the idea of the more commonly discussed features, like 1024 QAM (so 8 bits per symbol) and OFDMA (a hyper-cool way of sharing spectrum for lots of low throughput devices, like IoT things) but some of the more 'subtle' features that aren't often discussed are of great interest to me, with one being 'colour codes' (a concept used in DMR systems for several years) whereby you'll be able to ignore a neighbour's network devices that are being received at anything below -62 dBm - whereas currently, ones being received at above -82 dBm mean your network has to wait for them to stop sending before transmitting - so that selective sensitivity feature should help throughput when you live in an area with lots of surrounding wireless networks on the same channel as your one). Another cool one one increasing the symbol time and changing the guard interval options from 0.4 uS or 0.8 uS to 0.4 uS, 0.8 uS or 3.2 uS which means it can handle the bigger delay spreads likely to be encountered when using it certain types of outdoor environments (particularly so if there's a blocked line of site between the client and WAP). Of course, that will all only work if both the WAP and clients have 'WiFi 6' chipsets, but though I'll not be dipping into it early, it is certainly something to look forward to.
  2. Maybe Linn should simply bundle a 8 port Netgear unmanaged switch into every DS box and tell folks to connect everything to that (i.e. remove the ISP router's switch section from the equation and thus potentially something that's misbehaving when it comes to SSDP being unreliable)? Okay, I'm not being serious about Linn actually doing that, and no, it wouldn't solve everybody's problems (e.g. it won't tackle any wireless networking related issues) but in all seriousness, I'd bet that adding a £35 switch would dramatically lower the quantity of people who do have intermittent discovery problems. Actually, this is really a problem that Linn should discuss with their dealers (maybe they do) as in my opinion, the dealers should be keeping these Netgear switches in stock (or another known to be good make of switch in stock) and after a customer has bought their DS, the dealer should ask the customer about their network (and where deemed sensible - i.e. customer has only an ISP router - they should strongly advise the customer to consider buying one). For those that install DSs, they should always carry a stock of switches in their van and when they do find out that the home network uses only a cheap ISP router, they should very much encourage the customer to fork out the £35 in order to avoid potential problems with SSDP and control points occasionally not finding DSs (as of course, ISP's can remote update their router firmware, so even if it works now, there is always the potential of something changing after a firmware update, then of course, there is also the potential for a router to break, the ISP to send the customer a new router - that is often the first thing they do when you report a broadband fault - and there is always a possibility that the new model causes SSDP problems). Incidentally, on that same note one of my friends is a Talk Talk customer and after upgrading from ADSL to VDSL, he was sent a 'new' router, which turned out to be an ancient model (his current one was 802.11ac and the replacement was 802.11n, so that must have been sitting in their store room for many years). Amusingly, as his existing router already contained a chipset which understood both ADSL and VDSL, so nothing needed changing. Of course, I know that I have said this many times before, but it is worth pondering that I never have any discovery problems whatsoever, so the Linn kit does seem to be capable of running reliably, as long as nothing dodgy 'gets in the way' of things. All the best, Briain
  3. Hi As BB1 states, the ADS(&M) and KDS(&M) do not share the same output stage design. The Akurate has no output transformer, but it does have separate XLR and RCA output stages (to use technical talk, they are both buffered) whereas the KDS has a single output transformer for each channel, then the secondary of that transformer feeds the XLR and RCA sockets, so if you are using the XLR, plugging in an RCA cable (to another product) will partially unbalance the XLR output. This results in an uneven Voltage swing which could impact on sound quality of some products (as far as I am aware, no Linn device would be upset by this) but in some circumstances it can also result in hum problems. One of my friends bought a KDSM to use with non Linn balanced speakers (ATC ones) and a pair of unbalanced subs (B&W) and it wasn't useable due to the hum from the subs; he had to return the KDSM and buy a KK+KDS combination. I wanted to upgrade my KDS to a KDS/3, but that would mean retaining the KK to drive my 350A speakers and 345 sub, thus landing me in the above scenario. Whilst I don't have grounding problems here (bespoke mains system with nice, thick ground cables back to a central point) I didn't like the idea of doing that (it's complex as I use a miniDSP to do the sub filtering and the room is 9 m long, so the cables to front speakers and rear sub are also very long) so I sold the KDS and bought an ADSM (and had it immediately upgraded to Katalyst) and it works a charm. I was slightly irritated when I discovered that the two RCA sockets are simply connected together. I was assuming that they would be individually buffered as my plan was to use one pair for the sub and the other pair for a small set of active TV speakers (for when the main system isn't switched on) but as the RCA sockets aren't buffered, adding more long cables would potentially degrade the sound to the sub feed. Anyhow, the answer to your question is that the Akurate and Klimax boxes do have different output stages and I would have bought a Klimax DSM if they'd added another pair of transformers, but of course the box is too small to fit a second pair in, so that was why I went down the ADSM route (as that does have independent XLR and RCA output stages, so connecting my miniDSP + sub will - under all circumstances - have absolutely no impact to the sound of the main XLR feed to my 350A speakers (whereas with a Klimax box, the results cannot always be predicted). Hope that clears it all up, Briain
  4. At my last house, I had a MDSI in the TV room (feeding 212s) and I eventually procured myself a 2250. Almost immediately after connecting it all up, I was rather dismayed at just how boring it sounded (lovely effortless power, but just tedious to listen to); I remember actually thinking 'oh heck, what have I done spending money on this junk' but fortunately, before the 2250 had even arrived I'd ordered the Dynamik upgrade kit for it and that duly arrived the next day. After fitting it, the difference was really quite astonishing (and then some); I was then very happy with my 2250 purchase. I have heard the 2200 and 4200 in many systems, but sadly, I've never had the opportunity to directly compare a Dynamik 2250 to a Dynamik 2200. I think it would be intriguing to do so and I genuinely have no idea what the outcome would be.
  5. I felt sorry for dealers when DS's first came to market as likely very few of them would have had any network experience*. I can see why Linn Products wrote instructions based on adding a second router and thus being able to write concise instructions on how to set it up (even proposing the address range, etc) but that isn't a fix suitable for everybody, so they will likely have to dive into many existing networks and figure out how to bind a NAS, for example. One problem I've encountered (several times) is that whenever visiting someone's network to do something, you end up taking ownership and thus being responsible for clearing any other problems (new or existing) and that can be rather tedious. That's typically simple on a small home network, but for example, a couple of years back I had to deal with a very significant home (more like mansion) network with lots of co for mplex devices including a VoIP telephone exchange and other such 'toys' (nobody prior to me had left records and for some things, I had no access to even view their configuration). On that network, some things had been given fixed IP addresses and there was even a collision with the DHCP pool (causing utter chaos). Incidentally, I wasn't there to work on Linn kit but he did have a full sized rack housing his Knekt equipment (and a home cinema that actually resembled a cinema; very cool, it was). :-) Of course, there will also be dealers who don't want to dive into any network - even a simple one - not only due to it taking time on the day, but also due to the potential for subsequent customer calls stating 'well it was all okay until you touched it, get back out and fix it (for free)'. On a similar note, another interesting thing that I have oft' pondered is whether a dealer would prefer to sell a Linn DS based system or a similarly priced system from a competitor? Either sale might involve a similar quantity of time performing a home visit and to set the systems up, but in addition, the Linn one could (should) also entail spending quite some additional time faffing about with Space Optimisation. Briain * I was just a happy go lucky radio bloke back then and thus I also had virtually zero experience with LANs, then buying a KDS in 2007 forced me to get acquainted with networks, fix problems relating to same and now I'm not only working on small business networks, but at home I'm running a bunch of VLANs, several NAS's, several Raspberry Pi 'servers' (including one that uses internet radio streaming software for vaguely nefarious radio type purposes and another to monitor WAPs at several remote sites) and I'm now using an enterprise grade firewall instead of a router (including a reverse proxy for an internet facing web page; yes, yet another R Pi, of course). So, 13 years of network related utter misery all began from me just wishing to play an entire <beeping noise> album without having to change the side half way through; Linn <beeping noise> Products have an awful lot to answer for!
  6. Hi I think that a rather cool way to ponder what's going on with the address reservation is to consider each reservation as being like creating a tiny DHCP pool containing only one address. In other words, as far as the device requesting its network settings (including an IP address) from the router is concerned, it is much the same procedure as requesting its network settings from a bog standard DHCP pool of many addresses, except that in this case, it (or more accurately, it's MAC address) is only ever going to assigned that one, reserved address. Another router feature it's worth being aware of is DHCP lease time. This feature exists in all routers, but is sometimes not configurable in ISP issued routers (in other words, it isn't accessible in the router's web settings pages, but it still exists). The idea of this is that if you switched a device off for a few hours, the router 'remembers' that device existed and doesn't issue the address to anything else that you switch on (unless it really has to; i.e. unless all the other addresses in the DHCP pool have been taken by other things) and thus when you switch the device back on, it does typically get the same address as it had before you'd switched it off (it's sort of like a short term DHCP address reservation feature). The default setting for DHCP lease time - chosen by the router manufacturer - is typically a day or so (I have seen some set as low as 12 hours and others set at more than 3 days) and the reason I mention it is that [very rarely] I have read of instances where a newly connected product appears to be working just fine, then next day it seems to have an 'issue' of some description and after lots of investigation it's been found to be down to the re-negotiation of network settings at the DHCP lease time expiry (in other words, if the DHCP lease time is set to 3 days, after that 3 days the DHCP process is triggered off - this is how it is meant to work - but for some strange reason, that renegotiation process upsets something and that's what puts the ball up onto the slates. It is highly unusual for that to cause a problem, but it is worth being aware that it exists when trying to work out why something was working, then stops working after a day or so; the issue just might be associated with the DHCP re-negotiation after the DHCP lease time had expired. I haven't come across the above issue on any of my own fault chasing escapades, but I do seem to recall an incident (on the old Linn forum) whereby a Linn product was getting unhappy after a router (perhaps a Netgear model, I think, but it was ages ago so I could be wrong about that) 12 hour DHCP lease time negotiation had occurred. I cannot recall whether using MAC / IP address reservation helped or not (as they'll still be subject to the re-negotiation process after the lease period expires, but of course, they will always get the same reserved address) but it is just another oddball thing to be vaguely aware exists, just in case anyone comes across something that happens x hours after a reboot appeared to have sorted things. One last point about DHCP reservation is that when you do consider it as described in my first paragraph, it perhaps explains why some [typically cheap and nasty, but not always] routers only permit you to bind an address from within the scope of the DHCP pool (that really irritates me, but there's no 'law' against it) whereas with decent kit, you can typically bind addresses from outside the DHCP pool (and with some, only from outside the pool). I prefer the latter (at least the option to bind outside the pool) as to me, it seems a lot more logical to have them separated from the pool. Off to go play with some radio stuff now. :-) Briain PS Incidentally, absolutely everything on my internal networks (other than the guest network, obviously) uses DHCP assigned MAC/IP bindings. It needn't be, but by creating a list of network hosts in my 'router' it means that I can access them by name, rather than having to remember their IP address (so by naming my printer 'printer', I can simply type http://printer. into my browser and access the printer settings page, for example) but I doubt that's possible in any ISP issued router.
  7. Hi Always great to hear when a reboot fixes things and fingers crossed that the issue was just a one-off event. That some folks do have to occasionally reboot everything does point to an underlying problem and as stated in my post, I suspect that in many cases it's just down to the low grade ISP supplied routers, and even though the hardware is very low end, I suspect it's even more likely to be down to the firmware that's installed upon them misbehaving. Why I repeat all that is that the only time I have to reboot my 'router' is after a firmware update and I never have to also reboot any other devices (actually, that's not quite correct as I've had an ADSM go completely comatose twice over the past 12 months - which I've never had before - but that was more drastic than just network discovery as even the IR remote stopped working, and yes, a DS restart fixed it; obviously that was related to a Linn firmware glitch as since update it it's never happened again) and I'm running the same DS and control points as everybody else is running, so the only differences that I can think of (why I don't have issues and some other folks do) are severe wireless interference or the ISP supplied router is junk, and I strongly suspect it to be the latter. I hope that it now works for many months without needing another DS and/or network reboot; from my experience, that is the level of reliability that you should expect (and if it doesn't behave well going forward, I'd advise that you try some of the things I suggested in my long post, with adding a cheap switch being not too bad a place to start your 'faulting by substitution' type investigations). Briain
  8. Hi I've had a DS based system since 2007 and over the years, I have chanced upon a few unexpected problems when helping others to get a more reliable system, so below are a few examples of what can go wrong with ISP provided router/swtch/WiFi combination boxes (NB followed by an interesting finding pertinent only to Linn's firmware, where everything but a Linn system worked). For examples of 'router' related issues, a good few years ago there were a couple of models Zyexl router models where the manufacturer had provided a quality of service (QoS) feature (which is something almost no home user would ever use, but that Zyxel marketing folks likely thought would looked good on the side of the glossy packaging) and the poor implementation of that feature (even when it was disabled) caused havoc with discovery (in that case, not just Linn devices, but also other control points and media players). Back then, there were also a bunch of ISP routers that caused problems, most infamously the first and second series of BT Homehub (which I always called the 'Hometub') which were an absolute disaster in terms of discovery being blocked (I suspect that resulted in a few DSs appearing on eBay, back in the day)! In that case, the answer was simply to buy a cheap Netgear switch and by plugging one port of the router into that switch, then everything else into the other ports of the switch (and nothing else into the router) it meant that in terms of the devices in your own home 'talking' to each other', nothing was then being 'dragged' through the BT Homehub's internal switch section - only traffic to the Internet had to pass through the BT Homehub - and the problems were immediately resolved; flawless DS and media server discovery was achieved). I have heard of one (relatively obscure) unmanaged switch that did caused discovery problems in that sort of network layout, but I suspect that was just down to sloppy firmware (AKA a bug), but the wee blue metal boxed Netgear GS108 has always been a very safe bet for resolving such problems. Okay, I mentioned a couple of examples of specifically bad 'routers' in the above, but it is worth noting that most (probably all) ISP's tend to source the most basic hardware that they can lay their hands on (so they can then hand them out free, or at a very low price for a new customer) and worse than that, they then tweak the firmware, not only to brand it, but sometimes to add 'useful' features, with - for example - a common example being where entering an incorrect URL into their browser, the router can redirect the user to a 'useful and friendly' ISP page, perhaps even suggesting where you might instead wished to go to; that 'handy' feature breaks LAN DNS. Of course, when you take an already super-cheap router then start customising (borking) the router manufacturer's firmware, there can also be other unforeseen consequences, so I just either skip (as in dump them into the skip) and typically install a Draytek router, or if someone really wants/needs to use their ISP router, I add a Netgear switch to avoid internal traffic having to pass through it. Of course, we now have to ponder the WiFI element of that cheap ISP router as even if we add a switch (so router, DS, PCs, NAS, etc) are all communicating only via the switch, a mobile phone or tablet control point will still be connecting to the ISP provided router/switch/WiFi box's wireless section, so that means traffic from the NAS/DS to the phone and back will have to traverse the ISP provided router/switch/WiFi box. Fortunately (and a little surprisingly, to me) doing just that with the BT Homehub didn't result in any device discovery problems, but there are no guarantees that simply adding a switch on its own will always fix things as we still have the ISP router potentially 'getting in the way', so if there were still problems in that scenario, the next thing I'd do is to add a separate Wireless Access Point (WAP) and disable the ISP router's internal WiFI section. Adding a separate WAP has other benefits, for example, a good WAP will likely have a far better antenna system than the (inverted F) internal antenna that you typically find in an ISP router (and to make matters worse, some are crammed in between other components, thus degrading their radio coverage capabilities) but also you can site it in a more suitable place to better cover the building. Proper WAPs also tend to give access to a bunch of settings that are not brought out to the interface in an ISP router, and an interesting one to play with if using iOS devices is changing the DTIM default setting of 1 to 3 (this can also help extend battery discharge times in the iOS devices) though that can also upset really old Android devices (I'm talking antiques, here)! Onto Linn firmware and a few years back, Linn totally redesigned their network stack from the ground up (from memory, it was released in Daavar 50) and though I don't know that many DS owners, two of my personal friend updated their DSs and their control points couldn't then find them. I proposed they revert to the previous release (Daavar 37, from memory) and the DS's magically re-appeared. Following some discussions, I discovered that one was using and old Netgear 10/100 Mb/s switch and the other was using an elderly 10/100 MB/s TP-Link switch. There's nothing intrinsically wrong with using 10/100 MB/s switches (after all, the Linn DS is also only a 10/100 Mb/s interfaced device; that's all the speed it needs and likely there'll be less internal noise generated than would be the case if they'd instead opted to use a 1 Gb/s interface) so it would seem to be the age of the switch rather than its speed. I did speak to the Linn guys about this as it was clearly only a 'problem' when using their new network stack and I even offered to send them one of the offending switches, but they pointed out - and this I agree with - that given you can replace them with a modern switch for about £30, why worry that an ancient switch's components have likely drifted so far out of specification that they're getting prickly about Linn's new network stack; good point, so I left it at that. Anyhow, one last thought is that given how much it costs to buy a NAS and DS, is it really unreasonable to consider spending some money on a nicer router/switch/WiFi unit like a Draytek (though that particular model might also necessitate engaging someone to configure it for you; it isn't at all difficult, but there are a lot of settings - the vast bulk of which you need not touch - which make it look daunting; it is meant for small businesses, so it does carry a lot of features, but it also has very 'robust' firmware). I'd actually go further and suggest that for the amount you can save by going for the model without a wireless section, you could buy a very decent WAP and use that instead (siting it in a more appropriate location to enhance your coverage) but again, that range is meant for the 'enterprise lite' market, so you might need to engage someone to set it up. Sorry, a long post, but I have been running robust networks for over a decade and I get no problems with anything (okay, some firmware releases for products - including Linn's ones - can contain bugs, but these are typically addressed quickly and an update resolves them). I ran a Draytek router, Netgear unmanaged switch and Cisco WAP for 5 years with no problems and more recently I've been running Sophos UTM (enterprise firewall) feeding a Cisco Small Business switch and Ubiquiti WAPs. Again, firmware slip-ups have happened, but they are normally fixed swiftly (or in the case of Ubiquiti WAPs, by reverting to a few firmware releases back) but none of these bugs have actually impacted on the functionality of my own network. Good network kit can make a significant difference, though! I use WhatsApp for making WiFi voice calls and when speaking to a friend who also has a sensible network (I think he's currently using a Draytek, but he is using M. Mouse WAPs) I get no audio drop outs (and I often stand outside my building when speaking) whereas I phone others and the audio frequently drops (albeit for just moments) and they are using ISP provided routers, so it's not just Linn kit that 'notices' bad network components. Briain :-)
  9. Hi Sorry for not chipping in in a more timely manner, but I don't often visit the audio forum, these days. Firstly, don't panic at the length of this post as you can ignore all the stuff that I've typed below the dotted line (the rest is just to help anyone searching for Twonky problems and finding this thread)! You were actually very close with the 'rpd' part, but it is actually rpc, where the 'rpc' part referrs to a (universal) technique known as sending a 'Remote Procedure Call' to a remote server. What I loved about Twonky was that there were a whole bunch of these Remote Procedure Calls that one could perform to make it do things or to change its settings, and below are just a few of handy ones: The handy Twonky RPC's (ones that most folks will find useful for day user 'maintenance'): These are used in the form http://IP:port/rpc/<command> so in the below examples, I'll just list the ones I have used on my own server (which resides on and it resides on the default port of 9000 (which can be changed; from memory, the ancient ReadyNAS used 8200). (restarts Twonky) (rebuilds Twonky database) (rescans for newly added media) (shows all settings in the Twonky ini file) These are the most useful ones, but as I'm very seldom here (and as there aren't old Linn posts available) it's wort appending this post with some more nerdy stuff, just in case in the future, it helps give ideas to anyone searching for answers on how to do something more 'bespoke' than just a database rebuild (so most folks can ignore all the below stuff). Incidentally, after entering the above, you should get a response in your browser window, for example, after entering the /rpc/restart command, by browser shows the below response: The server is restarting. This might take a few seconds. So if you get no response at all, check that you have typed the command correctly into the browser's URL field. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Format examples to illustrate using the more advanced Twonky RPC's (of which there are too many to list): You can also do a bunch of more 'geeky' type management things via using the 'set_option?' command, like setting or changing the paths to the media directories, moving the directory in which Twonky stores its database, move the directory that Twonky uses to store its image cache (shown below) pinning it to using a particular IP address (handy for servers that have more than one Ethernet port) or indeed, changing the port (so you can change it from 9000 to a port of your choosing). In fact, you can change many of the settings listed within the ini file (as shown by that get_all command) via variations on the below examples (the parameters being the names that you see in the ini file line, or from the get_all trick). (binds Twonky to a single IP, in this example, it would bind it to<your new chosen path> (changes cache directory)<your chosen max size> (sets maximum size that cache directory can grow to). Before performing any settings changes via RPC calls such as the above three, it is important to establish both where the ini file resides and what it is called (in case you have to manually edit it or delete it; see footnote) and that can be done via running the /rpc/get_all command and looking for the lines shown below: ininame= inipath= On one of my older NAS units, it was ininame=twonkymedia-server.ini, but on my current Qnap, it is now named (and located) as is shown below (and I've seen instances where it is called something else, too). Obviously, where it resides depends on the make of NAS (or even the model of the NAS and its particular RAID configuration). Example from my Qnap TS-453A: ininame=twonkyserver.ini inipath=/share/CACHEDEV1_DATA/.qpkg/TwonkyServerEU/appdata Example from another server: ininame=twonkyvision-mediaserver6.ini inipath=/etc/config I don't think that absolutely all of the ini file entries can be directly changed via RPC calls, but many of them can, and as I used to do a lot of testing work, some of these were very useful (for example, when debugging an issue where Twonky wasn't correctly parsing art from the FLAC files, I used the set_option?cachedir to move the cache onto a NAS share, so I could then easily inspect the cache for art problems). I also often had to install beta versions Twonky on several devices (I was once sent 4 beta versions over a 2 day period) and it was far faster to set each new instance up via entering the basic parameters by using a pre-written list of RPC calls (including applying the key, back in the day). Basically, I'm very lazy and it was a lot faster than navigating through and populating the Twonky web interface. A new one to test Internet access (introduced a few versions into Twonky 8): Of course, Twonky has radically changed since the days when I used to help debug features (I still use Twonky 6.0.39 as that facilitates fully custom menus, or 'trees' as they are actually called) so perhaps some RPC's have now been depreciated and others have been added, but I do have a pretty current version of Twonky 8 on one of my NAS units and as I use an enterprise firewall (with https inspection and thus I require my own 'certificate authority installed in the root certificate store on all my devices) I did have a problem with the new Twonky on-line system which it calls home to (to verify the license) when Twonky starts up. Okay, this will not be an issue for most folks, but as part of my investigations (in conjunction with Twonky support) one thing that I did find out was that the they had introduced a new faulting RPC (just a few versions back) which facilitates testing of the communication (from the Twonky server installation's perspective) back to their server, so it could be handy if anyone is experiencing an odd problem (as in, install or restart Twonky and you see no media) so I'll publish it here, just in case anyone ever finds it handy: On my one, they all failed (which is good as it shows that my 'firewall' - Sophos UTM - was doing its job) so I then sorted out a path to Twonky's www server and after re-running the above, I then got a successful result (the returned results shown below): Lynx authentication check list: TIME: OK RW: OK TLS: OK DNS: OK HTTP: OK HTTPS: OK DB: OK So, not many folks will have to use that back end test RPC, but it is a nice and fast test should you ever have an issue with Twonky 8 not showing media (first try the above to see if it can 'call home'). Bri PS If one makes a mess of the ini file via typos in the 'set_option?' type calls (and you cannot find and change which setting broke things) then as a last resort, it is entirely safe to delete the ini file and restart Twonky (or reboot the NAS) and that will build a new ini file, based upon settings in a default ini file (this is the file used to pre-configure Twonky with basic settings, like the paths to media directories on a particular vendor's NAS or their bespoke port, for example) but of course, you will have to re-apply any personal settings (changes to the paths and your key, for example).
  10. Just for some amusing reading... Many years ago, I often had to explain - to completely non-technical people - the concept of why making digital level changes (so for example, that could be by using a DVC type function, or when using a software package to change the levels in an an audio file, etc, etc) with a system that had inadequate word lengths causes significant degradation. My analogy was to use money, explaining that if you halved the value of £1.50, there would be no problem as it ends up being (hang on while I go find my abacus) 75 pennies, however, if you instead wish to give somebody a half of £1.51, you end up with a problem as there is no such thing as a 1/2 p coin; you are forced to either give them 75 pennies or 76 pennies (so either of these values now suffers from 0.5 'penny units' of quantisation distortion). Of course, if you then multiply them by two to get back to where we started, the solutions are either £1.50 or £1.52, so we are now an entire penny adrift. Increasing the word length by one digit is thus like introducing a half penny coin such that the rounding error can be eliminated when reducing the 'volume' of our money. Of course, if you didn't increase the word length and then you wished to apply a gain change process a second time (e.g. a second edit of your audio file) then it's like halving the 75 pennies (which were already 1/2 penny 'distorted' from the first halving process) so you now end up compounding it with yet another rounding error atop the first one; you can only end up with either 37 pennies or 38 pennies. To illustrate the point further, if you were to multiply either of these final sums of money back up by 4 - to get back to where we started - you can see that the two solutions would be £1.48 or £1.52 (thus demonstrating the effects of the second edit; one of these solutions is now 3 pennies adrift from where we started). Of course, if you don't use physical pennies and instead use a calculator, you can perform as many operations as you like and you end up getting lots of digits after the decimal point, so these additional digits are the direct equivalent to increasing a digital system's word length. Doing that, you can now divide the 151, then divide the 75.5, and you end up with 37.75 pennies (so we have now increased the word length by 3 digits) and thus we now have no error. Of course, when all that's been done, we could now dither our 37.75 back down to the original word length and we'd end up with just under 38 pennies, but that's a slightly trickier one to explain away in terms of piggy bank fodder (roughening the edges of the coins was the easiest way to 'side step' explaining that one properly; remember, they weren't highly technical audiences)! Bri
  11. Well, I must confess to being rather drunk when hearing the above, and having just listened to it once again (whilst sober; err, well, whilst moderately sober), it seems that when played via an ADSM's phono stage, my LP12 actually sounds a little bit more like the below... ...of course, one is merely jesting (we all already know that the above deck would totally blow an LP12 out of the water when it comes to pumping out a foot-tapping tune or two)!!!! Nah, it did sound pretty darned splendid, so nothing to worry about (other than my rather strange sense of humour, of course).
  12. Hi I keep meaning to have a look at the board, but my understanding is that it is 'reversible' (so fitting one way makes it MM, then fitting it the reverse manner makes it MC) so that is quite a cool feature. Bri
  13. Hi I was really quite surprised at just how good the MC input sounded when using an ADSM/1 (this was tried with a top notch LK12 with Lingo 4 and played through my Klimax system) so I would like to hope - indeed, I'd fully expect - that the MM variant of same is rather fine sounding, too! Bri
  14. Many years ago, I attended a dinner in a very posh Edinburgh restaurant (it was located under the Scotch Malt Whisky Society in Giles Street). My friend - a Linn dealer, at the time - picked the venue for our shop Christmas dinner and a few of the Linn folks were also attending, with the surprise being that on a huge shelf above the bar, the owner had a pair of Isobaiks sitting on their sides. This worked really well as not only did they radiate forwards from the front units, but the top units were now side units, thus better covering the entire restaurant space. From memory, the source was just a Marantz CD player (and I cannot recall what the amp was, though I suspect it was an integrated one) but as the system was just used to play very quiet classical music, it all sounded very good (and the Isobariks looked really good on their side in that location; it all just aesthetically worked perfectly). The restaurant has, since then, changed hands at least once (and thus they'll not be there now) but next time I see my friend, I will ask if he has any pictures (as he installed them, back in the day). It turned out to be a good night out, but one of the chaps from Linn's car alarm went off, so a few of us nipped out the side door to have a look. This door was not meant to be used and outside it, there was an unguarded stone stair going down to the cellar, so it ended up with at least two folks taking a tumble (with some minor injuries) then shortly after that - in a completely unrelated incident - another customer slipped and banged his head on a radiator (nasty bump, but he was okay) so all in all, it was a night of carnage (with fine food and lots of nice wine, too).
  15. Hi Billz I was planning to use the case for a high current (home-brew) 13.5 V power supply, but before scrapping the board, I had a quick poke about inside it to see what had been taken out. There are (err, were) protection diodes just beyond the XLR inputs and these are completely fried. They are 3 leg devices (they are diode pairs) and with them being surface mount devices (SMD), they are quite small, but they're not 'mobile phone small' and there's enough space around them that it should be quite easy to change them. Beyond them, there are some SMD operational amplifiers at least 3 of which are also fried, but they are the package type that has small legs extending from them, so though tricky to change, I think I could do so without needing highly specialist SMD re-working equipment. A while back, I was given another 2250 board which had suffered a catastrophic failure (one of the speaker cables had been short circuited when it was playing at high volume; one of the printed circuit board tracks - feeding DC to the big amp ICs - had vaporised and the power supply capacitor cases had ruptured) but I suspect that the diodes and op amps might be okay (I have yet to check that) so it just might be possible to extract enough parts from that board to repair the one in your old 2250. Also, I have a couple of spare pre-Dynamik 2250 power supplies, so I'll probably use one of these, just to be safe. That it was belting out white noise at full volume in one channel might imply that at least in one channel, the big power amp ICs are functional (and I might have three good ones from that other amp; only one channel of that one was shorted, but I don't know how much was damaged when the power supply Voltage soared after the track got vaporised) so yes, it is possible that I'll have enough bits to make one working amplifier, but replacing SMD devices (without the specialist kit) always runs the risk of lifting printed circuit board tracks in the process, so that is perhaps another 'got-ya' that I'll have to take care to avoid. Being old, I'm good at working on older printed circuit boards, but I have very little experience on SMD component replacement, so I have just procured a very cool 4 piece SMD handling tweezer set (I only paid £10 at a radio event and they're normally £55) and I plan to get a SMD grade soldering iron, then hone my SMD re-working skills by first using something like a scrap computer motherboard, then I'll have a crack at getting the 2250 going. I don't need another 2250 (if it had a Dynamik, I might have used it to bi-amp my 212s) but rather than just use the box for a project, at some point forward I will try to get it running, just for the sheer fun of doing so (I could perhaps use it in my long planned kitchen sound system project) but of course, closer examination might reveal that both amp boards have more expired parts than my cursory testing found (I only spent a few minutes poking about at your board). I have a bunch of other projects that need first be done (I've not yet even created a permanent workshop area in this house; I'm still using the lounge dining table) but yes, I am really looking forward to having a crack at making it go again (I hate seeing something nice going into a recycling skip)! Bri