Polanskiman

Well that should be taken care of by module tg3 which is under DSM 6.2 (loader 1.03b). IG-88 also has a custom extra.lzma with a working tg3 module.

Certain liens étaient cassés dans le tuto. Je les ai mis à jour.

Some links were broken in the tutorial. I updated them.

Because that tutorial is not from this forum I can't vouch for its validity. I suspect though that it was based and inspired on the one I made. Try with the tutorial I made (see my signature). Also I would recommend you use loader 1.03b (3615xs) if you want to go to DSM 6.2. If not then use 1.02b (3615). You wont be able to go beyond DSM 6.1.7 with that loader Also the specs of that machine are not very detailed and there is no mention about what NIC is used. You might want to check what NIC it is because that might be the issue. Beyond DSM 6.2 the range of possible NICs that can be use is considerably reduced. Intel is preferred.

Olegin answered to that question already but I wanted to add some more. The OS (DSM) running on your XPEnology Box is the same as the one running on a genuine Synology box. In other words, DSM in your Xpenology box is as genuine as the one in a Synology box. This said once you put the drives in a Synology Box, DSM will most certainly ask you to reinstall DSM if the model (918, 3615, 3617) you are moving your drives to is not the same as the model of the loader your used to initially install DSM in your Xpenology box. Your data should remain safe.

What loader did you use on the Dell Optiplex 3020? What loader did you use on your in-law and what hardware do they have?

This is explained in the FAQs.

The question(s) in this topic have been answered and/or the topic author has resolved their issue. This topic is now closed. If you have other questions, please open a new topic.

That's not a major update. That's an intermediate update. Note that I said "usually". I do not warranty an intermediate update will not update that file. In fact even a critical update could potentially update that file if Synology decided to, say correct a bug that involved anything related to that file.

Not sure what hack you did since you do not detail it but if I am not wrong you simply modified the synoinfo.conf file. That means that after (usually) a major update the file will be overwritten with the one contained in the update thus crushing any edits you did to it. Here is a way to overcome this:

That is the actual patching command line (with the -p flag). If you only do what follows: ./patch.sh then you are merely calling the patch help and nothing is done (no patching, no backing up). It's the same as doing: ./patch.sh -h I could be wrong but the reason why the author did not put the actual full patching command line in the OP is because: 1. it lets the user understand what he is doing and the capabilities of the patch; 2. it reduces the possibilities of error as the user is forced to read instead of just copy pasting command lines and not understanding what is happening. In your case you should now be good to go. If you use PhotoStation / VideoStation you should not have any issue now and if you look at the /var/log/messages you shouldn't see errors such as: 2020-01-30T12:14:08+07:00 Server synocodectool: SYNOCodecPatentG1.cpp:239 ValidateG1Licence failed 2020-01-30T12:14:08+07:00 Server synoflvconv: synoflvconv.cpp:617 Failed to convert video [/volume/photo/Pictures/IMG_3.MOV] t$ In the future I would advise against running command lines if you don't know what it is doing and how it works. Better to ask prior any action.

The question(s) in this topic have been answered and/or the topic author has resolved their issue. This topic is now closed. If you have other questions, please open a new topic.

The question(s) in this topic have been answered and/or the topic author has resolved their issue. This topic is now closed. If you have other questions, please open a new topic.

My intention is not for you not to participate, rather the opposite and I am sorry if you felt offended. This said, your question has nothing of a noob question but rather of someone who clearly didn't take the time to read and reflect. The "tutorial" you are asking for is literally detailed in the OP, so I am not sure what else you are looking for. Perhaps explaining what it is that you do not understand would help us, help you.

Tutorial on what exactly? The process is rather explicitly detailed in the OP as well as github link provided. Or am I missing something?

Thanks for those details.

Yes the patch restores the ability to allow video playback as well as showing video thumbnails in PhotoStation. I suppose the same applies to VideoStation and perhaps other applications that were relying on license checking. For the videos to be playable again and thumbnails to show back one needs to re-index media in PhotoStation > Settings > Photo > Re-index Additionally this patch will most certainly be overwritten during DSM updates, therefore it will need to be reapplied following an update. @likeadoc can you please confirm this?

This tutorial is to update to DSM 6.1. The person wants to install DSM 6.1 not DSM 6.2. Loader v1.02b is perfectly suitable for that or did I miss something? This said @than you could still update to DSM 6.2. However you would need loader v1.03b (assuming you are using DS3615xs/DS3617xs) as mentioned by @IG-88. No need for a new NIC if you do not go beyond DSM 6.2 (DSM 6.2.1, DSM 6.2.2) in which case you will need preferably an intel NIC (HP NC360T card for example). Did you disable C1E in the bios? As stated above you do not need a different NIC for DSM 6.2. Only for versions above that (DSM 6.2.1 and higher). Also if you are upgrading from DSM 5.2, you will need after the update to delete the .xpenoboot directory under Root (/) via ssh.

For the community, please note that this critical update does NOT apply to DS3615xs and DS3617xs.

To quote you: Good point.

The question(s) in this topic have been answered and/or the topic author has resolved their issue. This topic is now closed. If you have other questions, please open a new topic.

Good call on the CPU. DS3617xs always had some issues where the GUI stops working at some point due to some shared libraries having some invalid ELF header. I am not sure why this happens but I have not seen this happen on DS3615xs. It's not a drama as it is possible to fix this rather easily. The libraries in question are libsynopkg.so.1 and libsynoshare.so.6. It's just a matter of replacing them with those from the PAT file. For reference:

A word of caution here. DS3617xs has some issues which have been documented over and over again in the forum. Issues might arise randomly in a week, a month or a year. It's easily fixable yet problematic as you have a sword over your head. @IG-88 Can DS3615xs be used with his hardware?

Avez vous désactivé la carte réseau interne de la carte mere?

Deja il faudrait commencez par nous donner le switch que vous utilisez et le le type de Bond que vous essayer de faire.